1 /*
2 * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights reserved.
3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
4 *
5 * This code is free software; you can redistribute it and/or modify it
6 * under the terms of the GNU General Public License version 2 only, as
7 * published by the Free Software Foundation. Oracle designates this
8 * particular file as subject to the "Classpath" exception as provided
9 * by Oracle in the LICENSE file that accompanied this code.
10 *
11 * This code is distributed in the hope that it will be useful, but WITHOUT
12 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
13 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
14 * version 2 for more details (a copy is included in the LICENSE file that
15 * accompanied this code).
16 *
17 * You should have received a copy of the GNU General Public License version
18 * 2 along with this work; if not, write to the Free Software Foundation,
19 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
20 *
21 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
22 * or visit www.oracle.com if you need additional information or have any
23 * questions.
24 */
25
26 /**
27 * Provides reference-object classes, which support a limited degree
28 * of interaction with the garbage collector. A program may use a
29 * reference object to maintain a reference to some other object in
30 * such a way that the latter object may still be reclaimed by the
31 * collector. A program may also arrange to be notified some time
32 * after the collector has determined that the reachability of a given
33 * object has changed.
34 *
35 *<h2>Package Specification</h2>
36 *
37 * A <em>reference object</em> encapsulates a reference to some other
38 * object so that the reference itself may be examined and manipulated
39 * like any other object. Three types of reference objects are
40 * provided, each weaker than the last: <em>soft</em>, <em>weak</em>,
41 * and <em>phantom</em>. Each type corresponds to a different level
42 * of reachability, as defined below. Soft references are for
43 * implementing memory-sensitive caches, weak references are for
44 * implementing canonicalizing mappings that do not prevent their keys
45 * (or values) from being reclaimed, and phantom references are for
46 * scheduling post-mortem cleanup actions.
47 * Post-mortem cleanup actions can be registered and managed by a
48 * {@link java.lang.ref.Cleaner}.
49 *
50 * <p> Each reference-object type is implemented by a subclass of the
51 * abstract base {@link java.lang.ref.Reference} class.
52 * An instance of one of these subclasses encapsulates a single
53 * reference to a particular object, called the <em>referent</em>.
54 * Every reference object provides methods for getting and clearing
55 * the reference. Aside from the clearing operation reference objects
56 * are otherwise immutable, so no {@code set} operation is
57 * provided. A program may further subclass these subclasses, adding
58 * whatever fields and methods are required for its purposes, or it
59 * may use these subclasses without change.
60 *
61 * <h3>Notification</h3>
62 *
63 * A program may request to be notified of changes in an object's
64 * reachability by <em>registering</em> an appropriate reference
65 * object with a <em>reference queue</em> at the time the reference
66 * object is created. Some time after the garbage collector
67 * determines that the reachability of the referent has changed to the
68 * value corresponding to the type of the reference, it will clear the
69 * reference and add it to the associated queue. At this point, the
70 * reference is considered to be <em>enqueued</em>. The program may remove
71 * references from a queue either by polling or by blocking until a
72 * reference becomes available. Reference queues are implemented by
73 * the {@link java.lang.ref.ReferenceQueue} class.
74 *
75 * <p> The relationship between a registered reference object and its
76 * queue is one-sided. That is, a queue does not keep track of the
77 * references that are registered with it. If a registered reference
78 * ceases to be strongly reachable itself, then it may never be enqueued. (See the
79 * <a href="#reachability">Reachability</a> section for a description of
80 * different types of reachability.) It is
81 * the responsibility of the program using reference objects to ensure
82 * that the objects remain strongly reachable for as long as the program is
83 * interested in their referents.
84 *
85 * <p> While some programs will choose to dedicate a thread to
86 * removing reference objects from one or more queues and processing
87 * them, this is by no means necessary. A tactic that often works
88 * well is to examine a reference queue in the course of performing
89 * some other fairly-frequent action. For example, a hashtable that
90 * uses weak references to implement weak keys could poll its
91 * reference queue each time the table is accessed. This is how the
92 * {@link java.util.WeakHashMap} class works. Because
93 * the {@link java.lang.ref.ReferenceQueue#poll
94 * ReferenceQueue.poll} method simply checks an internal data
95 * structure, this check will add little overhead to the hashtable
96 * access methods.
97 *
98 * <a name="reachability"></a>
99 * <h3>Reachability</h3>
100 *
101 * Going from strongest to weakest, the different levels of
102 * reachability reflect the life cycle of an object. They are
103 * operationally defined as follows:
104 *
105 * <ul>
106 *
107 * <li> An object is <em>strongly reachable</em> if it can be reached
108 * by some thread without traversing any reference objects. A
109 * newly-created object is strongly reachable by the thread that
110 * created it.
111 *
112 * <li> An object is <em>softly reachable</em> if it is not strongly
113 * reachable but can be reached by traversing a soft reference.
114 *
115 * <li> An object is <em>weakly reachable</em> if it is neither
116 * strongly nor softly reachable but can be reached by traversing a
117 * weak reference. When the weak references to a weakly-reachable
118 * object are cleared, the object becomes eligible for finalization.
119 *
120 * <li> An object is <em>phantom reachable</em> if it is neither
121 * strongly, softly, nor weakly reachable, it has been finalized, and
122 * some phantom reference refers to it.
123 *
124 * <li> Finally, an object is <em>unreachable</em>, and therefore
125 * eligible for reclamation, when it is not reachable in any of the
126 * above ways.
127 *
128 * </ul>
129 *
130 * @author Mark Reinhold
131 * @since 1.2
132 */
133 package java.lang.ref;