[Conclusion] Design Pattern-Singleton pattern

 

Today is the first day of the course at the Chinese Emy of Sciences chuangsi branch. Many of my feelings are the stains of my previous thoughts.
In the past, I ignored the importance of basic knowledge and thought that my basic knowledge was relatively powerful. However, one hour after I attended a lecture at the Chinese Emy of sciences, I suddenly found that my foundation was so unsystematic, not comprehensive, not in-depth enough. This is why I feel stunned today. I cannot think of good words to describe my mood. I can only use this word, I think this word can express my fear and a little lucky mood. The teacher lectures here are indeed more systematic and more detailed, and the examples are also more classic. I really regret why I didn't come to this school to study the system earlier, so that I would not take many detours. (Note: I am not a gunman)
The above is my feelings about today's class, and the following is what I said yesterday about my design mode communication platform. I hope you will not laugh, share, and improve.
Entry into question: Design Model-singleton Singleton Model
In many designs, we use this mode when controlling the entire JVM to generate only one object, for example, you cannot display multiple interfaces during the entire software running period. In terms of terms, you can only create one such object in the entire JVM.
When designing such a model, cainiao often uses a static counter to determine whether to load new objects. However, it is not feasible to think about it, especially in the case of high concurrency, the spam is terrible.
1. many people always want to manually control the class instantiation. Simply put, they want to instantiate the class for their own judgment and then instantiate it through the business logic, I don't know how this will bring a high degree of reliability to the program, and at the same time, it will put my own thinking under more tests, there is no perfect program. This "day" always tests the code and worries about unexpected problems.
2. Since it is better not to control the allocation of class instances by yourself, load the class or put the instance into the class so that it can judge and assign it internally.
For example:
A woman can only marry once (the woman is also the only one). If she asks her father (not herself) to control her daughter's marriage, her father may face numerous "Son-in-law" pursuits and invitations, as a father, he will bear the pressure of many people and he will force himself to make a lot of judgments (maybe at last, his father agreed to the marriage agreement between the two people ), this sort of parent-managed marriage is completely decoupled from her daughter. The best way is to allow her daughter to choose her own ruilang June. In this way, the father's fatigue problem is solved securely and securely, who will marry and those who will only marry once should be properly solved. Why not?

Through the above example, we have analyzed the single-instance management mode and summarized it as: Let the single-instance class control the Order and method of Instantiation or loading by itself, avoid inconsistency during multi-thread concurrency.
Next let's take a look at the simplest Singleton sample program:

1. Public class Singleton {
2. Private Static final Singleton = NULL;
3. Private Singleton (){
4. } Public static Singleton getinstance ()
5. {If (Singleton = NULL)
6. {Singleton = new Singleton ();
7. } Return Singleton;
8. }}

Private constructor is used to prevent explicit instantiation by others: instances like new Singleton () are not allowed.
Note: static final Singleton = NULL; some people will think that the final keyword will lead to a failure to load. In this case, the final will be wrong. For reference, the Knowledge locks the reference, however, the referenced memory can be modified because it is not like modifying the data in the stack.
Conclusion 1: The Singleton mode can be used to implement a basic Singleton. getinstance () is used to obtain an object. When the second request comes in, it first checks whether it has been used as an example, and then allocates or instances. the disadvantage is that, in the case of high concurrency and multi-thread, this will be completely invalid. If both threads have passed the null check of 10th rows, two objects will be taken out, it does not act as a Singleton, so the second version is available, as shown below:

1. Public class Singleton {
2. Private Static final Singleton = NULL;
3. Private Singleton (){
4. } Public static Singleton getinstance ()
5. {If (Singleton = NULL)
6. {Synchronized (singleton. Class ){
7. Singleton = new Singleton ();}
8. } Return Singleton;
9. }}

Synchronized usage I believe that I will know what it means when I have learned thread synchronization. This solution can barely work during low concurrency, however, there may still be two objects in the instance similar to the one in the first example, and only two objects are created for the first instance at the same time, changed to serial instances in a certain order to produce two objects, and the result is certainly not what we want.

In the second example, we think that multiple threads will skip the first to null to determine whether the instance object will be serialized. Can we instantiate the instance in the null way again, because there are a bunch of threads waiting in queue for collection, the singleton reference in the date segment will not be instantiated when it is not empty, if it is null, it indicates that someone has applied for an object in the current thread, so the following code is not considered:

Public class Singleton

{

Private Static final Singleton = NULL;

Private Singleton (){

} Public static Singleton getinstance ()

{Synchronized (singleton. Class)

{If (Singleton = NULL)

{Singleton = new Singleton ();

}}

Return Singleton ;}

} The row 12 locks the class, serializes the accessed thread, and makes a single judgment on the queue thread in an orderly manner. This solves the concurrency problem in a single example, calling, this decent Singleton has been successful. However, to solve the impact of locking on performance, we still use the following method to control instantiation, with only one line of code added:

If (Singleton = NULL) {synchronized (singleton. Class)
1. {If (Singleton = NULL)
2. {Singleton = new Singleton ();
3. }}}
4. Return Singleton;

The judgment of the first line shown above will reject all the threads in the future, which will improve the server performance very high.

At this point, code reuse for a single instance has been a problem, so you have to make some sacrifices at some time. In short, the single instance mode is still required at some times, it is necessary for some special business logic. I hope you can communicate with me, learn, and criticize and correct me.
Looking forward to the next phase of the new design model-factory Model