rev 15569 : [mq]: fix_bad_merge

   1 /*
   2  * Copyright (c) 1998, 2015, 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 pre-mortem cleanup actions in a more flexible way than
  47  * is possible with the Java finalization mechanism.
  48  * Post-mortem cleanup actions can be registered and managed by a
  49  * {@link java.lang.ref.Cleaner}.
  50  *
  51  * <p> Each reference-object type is implemented by a subclass of the
  52  * abstract base {@link java.lang.ref.Reference} class.
  53  * An instance of one of these subclasses encapsulates a single
  54  * reference to a particular object, called the <em>referent</em>.
  55  * Every reference object provides methods for getting and clearing
  56  * the reference.  Aside from the clearing operation reference objects
  57  * are otherwise immutable, so no {@code set} operation is
  58  * provided.  A program may further subclass these subclasses, adding
  59  * whatever fields and methods are required for its purposes, or it
  60  * may use these subclasses without change.
  61  *
  62  * <h3>Notification</h3>
  63  *
  64  * A program may request to be notified of changes in an object's
  65  * reachability by <em>registering</em> an appropriate reference
  66  * object with a <em>reference queue</em> at the time the reference
  67  * object is created.  Some time after the garbage collector
  68  * determines that the reachability of the referent has changed to the
  69  * value corresponding to the type of the reference, it will clear the
  70  * reference and add it to the associated queue.  At this point, the
  71  * reference is considered to be <em>enqueued</em>.  The program may remove
  72  * references from a queue either by polling or by blocking until a
  73  * reference becomes available.  Reference queues are implemented by
  74  * the {@link java.lang.ref.ReferenceQueue} class.
  75  *
  76  * <p> The relationship between a registered reference object and its
  77  * queue is one-sided.  That is, a queue does not keep track of the
  78  * references that are registered with it.  If a registered reference
  79  * becomes unreachable itself, then it will never be enqueued.  It is
  80  * the responsibility of the program using reference objects to ensure
  81  * that the objects remain reachable for as long as the program is
  82  * interested in their referents.
  83  *
  84  * <p> While some programs will choose to dedicate a thread to
  85  * removing reference objects from one or more queues and processing
  86  * them, this is by no means necessary.  A tactic that often works
  87  * well is to examine a reference queue in the course of performing
  88  * some other fairly-frequent action.  For example, a hashtable that
  89  * uses weak references to implement weak keys could poll its
  90  * reference queue each time the table is accessed.  This is how the
  91  * {@link java.util.WeakHashMap} class works.  Because
  92  * the {@link java.lang.ref.ReferenceQueue#poll
  93  * ReferenceQueue.poll} method simply checks an internal data
  94  * structure, this check will add little overhead to the hashtable
  95  * access methods.
  96  *
  97  * <a name="reachability"></a>
  98  * <h3>Reachability</h3>
  99  *
 100  * Going from strongest to weakest, the different levels of
 101  * reachability reflect the life cycle of an object.  They are
 102  * operationally defined as follows:
 103  *
 104  * <ul>
 105  *
 106  * <li> An object is <em>strongly reachable</em> if it can be reached
 107  * by some thread without traversing any reference objects.  A
 108  * newly-created object is strongly reachable by the thread that
 109  * created it.
 110  *
 111  * <li> An object is <em>softly reachable</em> if it is not strongly
 112  * reachable but can be reached by traversing a soft reference.
 113  *
 114  * <li> An object is <em>weakly reachable</em> if it is neither
 115  * strongly nor softly reachable but can be reached by traversing a
 116  * weak reference.  When the weak references to a weakly-reachable
 117  * object are cleared, the object becomes eligible for finalization.
 118  *
 119  * <li> An object is <em>phantom reachable</em> if it is neither
 120  * strongly, softly, nor weakly reachable, it has been finalized, and
 121  * some phantom reference refers to it.
 122  *
 123  * <li> Finally, an object is <em>unreachable</em>, and therefore
 124  * eligible for reclamation, when it is not reachable in any of the
 125  * above ways.
 126  *
 127  * </ul>
 128  *
 129  * @author        Mark Reinhold
 130  * @since         1.2
 131  */
 132 package java.lang.ref;
--- EOF ---