Implementation and invocation principle of large object caching

In the UOP data cache I introduced the general principle of object caching, where the large object caching is simply
The basic principle is introduced. This article describes in detail how to cache large objects.

Based on the type of this column, the content discussed in this column is how to apply some technology to design the system properly.
Rather than introduce a basic technique. such as the concept of the secondary (soft)/weak/virtual reference of the object involved in this article, this is what you want yourself
Refer to the relevant information and control.


Large objects (Fat object) are those that take a certain amount of time when they are created, or occupy a certain amount of space after the creation is completed.
Like, to put it simply, is "Hard-won" ah. such as graphic objects, socket links and so on. So this kind of object should not be created frequently
Built. It should be used as much as possible to buffer. Object Buffering does not just refer to the cached object itself, but includes multiple reuse.

However, because such objects occupy a larger space, if the use of the frequency is not high and can not be placed in memory for a long time, so in
There is a contradiction between persistence and creation. Neither can be recreated each time, nor can it be persisted once created.

Forget it, it's so annoying, it costs so much brains to do. It's up to the JVM to decide.
The large object caching principle is given to the JVM for its own decision on the grounds that:

If the JVM has a resource recycle, which means that the space is tight now, then these big objects should make room. and normally, the JVM
There is no resource recovery, there is a certain amount of space redundancy, so try to let such a large object live longer. Reduce
The probability of a duplicate creation.

To achieve the above conditions, there is no strong reference, if there is a strong reference to hold such a large object, whether if the JVM
This object will not be recycled when the resource needs to be recycled.


So, after we create a large object, we either don't hold the strong reference to the object, or immediately after the strong reference
Interrupts an association between an object and a reference.

SoftReference sr = null;//declares an instruction for saving the returned object.

if (Sr==null | | sr.get () ==null) {
sr = new SoftReference (new Fatobject ());
}

Each time we can get this large object from Sr.get (), as long as sr.get () is null, the original object has been
is reclaimed, and will be regenerated the next time it is called.


The object that is generated, if we assign it to a strong reference handle, such as:

Image img = (image) Sr.get ();
Then, after calling the IMG reference complete, be sure to IMG = NULL to interrupt the reference handle IMG association with that large object.
Otherwise, when the JVM is GC, it cannot be reclaimed, and the resource cannot be freed. And this programming doesn't fit
Often return programming habits, than unexpectedly, Java is automatically recycled memory, unlike C + + programmers will remember the manual after using the object
Clears the object so that the Java programmer manually executes handler = NULL each time the object is finished using it;
It's not the same thing.

In fact, C # 's properties are a very good way, although class.attribute like a field that references a class, but actually
is to invoke the GetXXX method. In Java, we have to refer to the large cache object, although it is still not the most conventional learning
accustomed, but handler = null after each invocation: it is much more natural.

Class cacahedfatimage{
SoftReference sr = null;
String FilePath;
Public Cacahedfatimage (String FilePath) {
This.filepath = FilePath;
sr = new SoftReference (new Image (filepath));
}

Public Image GetObject () {
if (Sr==null | | sr.get () ==null)
sr = new SoftReference (new Image (filepath));
Return (Image) sr.get ();
}

}


At the time of the call, Mr. Cacahedfatimage object:

Cacahedfatimage CFI = new Cacahedfatimage ();
Later, when calling this large object, the Cfi.getobject () is used to replace the IMG reference.

such as: Cfi.getobject (). GetWidth ();
Cfi.getobject (). GetHeight ();


This way, as long as the object is not recycled we can get it at any time, and if the JVM needs to recycle, because there is no strong
Reference relationship, which can be reclaimed at any time.