As you can see, it is very easy to create a reference to our object curr in this case. All reference types take the referenced object in the constructor and, optionally, a queue as a parameter.
We can always reach the referenced object with the method get. In the case of Weak and Soft, get will return the actual object if still active — that is, if it is reachable by other objects. In case the object has been collected, get will return null. For this reason, Phantom always returns null in the get regardless of whether the object is still active. In this way, we can pass a PhantomReference to another object without risking that it will store a new, hard reference to it.
The other parameter in the constructor is the ReferenceQueue. To understand why is important, we have to consider how we know when the referenced object is finalized. For Soft and Weak references, we can check the get method, but it would be very time consuming if we have a big list of references. Moreover, for Phantom references, we cannot use it at all.
For this reason, if we pass a queue in the constructor of the reference, we will get a notification when the referenced object expires. In my simple example, I poll the queue after the deallocation:.
If queue. A less naive approach is to create a separate thread and call queue. Just remember that whilst Weak and Soft references are put in the queue after the object is finalized, Phantom references are put in the queue before.
Well, so now that we understand memory references better, what can we use them for? The Java documentation already suggests some uses for the references.
SoftReferences can be used to implement a cache that can grow without risking an application crash. To do this, you need to implement a Map interface in which values are stored, wrapped inside a SoftReference. SoftReferences will keep the objects alive until there is memory available on the heap, but it will discard them before an OutOfMemoryError. To further facilitate memory management, languages with garbage collection facilities may additionally enhance the functionality of a language by providing finer gradients of references other than the strong or weak reference.
Data types such as soft references and phantom references may be included in these languages, which allows for varying levels of object recapture or deallocation notification.
Programmers who use languages with automated garbage collection should familiarize themselves with all of the reference classes that are available in order to improve application performance. Rodney A. Weak references are useful for objects that use a lot of memory, but can be recreated easily if they are reclaimed by garbage collection. Suppose a tree view in a Windows Forms application displays a complex hierarchical choice of options to the user.
If the underlying data is large, keeping the tree in memory is inefficient when the user is involved with something else in the application. When the user switches away to another part of the application, you can use the WeakReference class to create a weak reference to the tree and destroy all strong references. When the user switches back to the tree, the application attempts to obtain a strong reference to the tree and, if successful, avoids reconstructing the tree.
To establish a weak reference with an object, you create a WeakReference using the instance of the object to be tracked. For a code example, see WeakReference in the class library. The target of a short weak reference becomes null when the object is reclaimed by garbage collection. The weak reference is itself a managed object, and is subject to garbage collection just like any other managed object.
A WeakRef object lets you hold a weak reference to another object, without preventing that object from getting garbage-collected. A WeakRef object contains a weak reference to an object, which is called its target or referent. A weak reference to an object is a reference that does not prevent the object from being reclaimed by the garbage collector. In contrast, a normal or strong reference keeps an object in memory. When an object no longer has any strong references to it, the JavaScript engine's garbage collector may destroy the object and reclaim its memory.
If that happens, you can't get the object from a weak reference anymore. Note: Please see the Avoid where possible section below. Correct use of WeakRef takes careful thought, and it's best avoided if possible.
0コメント