Implementation and calling principles of Large Object Cache

In the UOP data cache article, I introduced the general principles of object cache, which is simple to cache large objects.
This document describes how to cache large objects.

Based on the type of objective in this column, the content discussed in this topic is how to properly apply a certain technology to system design.
Instead of introducing some basic technologies, such as the concept of secondary (soft), weak, and virtual references of objects involved in this article.
Refer to the relevant materials.

A large object (fat object) is a pair that takes a certain amount of time during creation or takes up a certain amount of space after creation.
Like, simply put, it is "hard to come by" Ah. Comparison objects, socket connections, etc. Therefore, such objects should not be frequently created
It should be used as much as possible. The Object Buffer not only refers to the cache object itself, but also includes multiple reuse.

However, because such an object occupies a large amount of space, if the usage frequency is not high and cannot be put in the memory for a long time
There is a conflict between persistence and creation. It cannot be re-created every call, nor can it be permanently maintained once created.

Forget it, so much effort is required for the JVM to decide what to do.
The JVM determines the principle of caching large objects for the following reasons:

If the JVM recycles resources, it means that the current space is tight, so this type of large objects should free up space.
There is no resource recovery, which means there is still some space redundancy, so try to make such a large object live for a long time.
The probability of repeated creation.

To meet the preceding conditions, there must be no strong references. If a strong reference holds such a large object
This object is not recycled when resources need to be recycled.

Therefore, after creating a large object, either we never hold the strong reference of this object, or we need to immediately
Interrupt the association between objects and references.

Softreference sr = NULL; // declare an indication for saving the returned object.

If (Sr = NULL | Sr. Get () = NULL ){
Sr = new softreference (New fatobject ());
}

Every time we get this large object from Sr. Get (), as long as Sr. Get () is null, it indicates that the original object has
Recycled. It will be generated again next time.

If the generated object is assigned to a strong reference handle, for example:

Image IMG = (image) Sr. Get ();
After calling the IMG reference, it is necessary that the IMG = NULL; can interrupt the association between the reference handle IMG and that large object.
Otherwise, when the JVM performs GC, it cannot be recycled, and resources are always occupied and cannot be released. This programming method does not match
Normally, Java automatically recycles memory, unlike C/C ++.ProgramThe user will remember to manually
To clear objects, Java programmers must manually execute handler = NULL every time they use the objects.
Not the same thing.

In fact, the C # attribute is a very good way, although class. attribute is like referencing a class field, but in fact
The getxxx method is called. in Java, We Have To reference large cached objects in this way, although it is still not the most common practice
This is more natural than handler = NULL after each call:

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 ();
}

}

During the call, the Mr is a cacahedfatimage object:

Cacahedfatimage CFI = new cacahedfatimage ();
In the future, CFI. GetObject () will be used to replace the IMG reference when this large object is called.

For example, CFI. GetObject (). getwidth ();
CFI. GetObject (). getheight ();

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