[multithreading] realize the singleton mode (hungry and lazy) realize the thread safe singleton mode (double validation lock)

Catalog

•   The singleton pattern
•   What is singleton mode
•   Two classic implementations of singleton mode
•  1. Starving model ( Thread safety )
•  2. The sluggard model ( Thread unsafe )
•   Thread safe singleton mode
•  1. The sluggard model +synchronized Static synchronization method ( Thread safe but inefficient )
•  2. The sluggard model + Second judgment ( Double check lock , Thread safe and efficient )

---

The singleton pattern

What is singleton mode

Require a class in our code , There can be only one instance , Cannot have multiple instances .
Examples are objects .
That is, a class can only new An object , You can't new Multiple objects .

This singleton mode , It is very common in practical development , It's also very useful .
Many in development “ Concept ”, Nature is a single case .

such as ：

​ Use JDBC Operating the database , At this time, the database connection can be obtained through the database connection pool database connection

Log in and copy

    DataSource ds=new MySqlDataSource();

    Connection c=ds.getConnection() ;// Get database connection 

      

       
1.
       
2.
       
3.
      

The connection pool can use the singleton mode , Create a unique object .

Most things are related to , Only one copy is stored in the server . that , You can use “ The singleton pattern ” To represent .

---

Two classic implementations of singleton mode

There are two typical implementations in singleton mode ：

1. Starving model
2. The sluggard model

Let's talk about the hungry man model through a life example , What is lazy mode .

Wash the dishes ：

1. Case one ：
   Suppose we have lunch , The family used 4 A bowl . Then after eating , Wash the bowl right away
   This situation , Namely Starving model

2. The second case :
   At lunch , The family used 4 A bowl . Then after eating , Put the bowl first , Don't worry about washing
   Waiting for dinner at night , The discovery only needs 2 A bowl .
   Then we will 4 An unwashed bowl in , Wash out 2 A bowl , Use it . After eating , Put the bowl first , Don't worry about washing .
   If you only use one for the next meal , Just wash out 1 A bowl
   Just how much , Take how much . Not enough , No more
   This is it. The sluggard model

But in the computer , It is generally believed that The sluggard model Than The hungry man mode is good .
Mainly because The sluggard model More efficient

It's easy to understand ： wash 2 individual bowl , It must be better than washing 4 A bowl is easy .

So use a few to wash a few .
According to need , To operate .

“ lazy ” This word is general In the computer , It's a compliment .

---

1. Starving model ( Thread safety )

1. The hungry man mode class instantiates an object immediately when the class is loaded So follow up anyway As long as it is strictly used get Method There will be no other instances
2. It can be seen from the above that Hungry man mode is thread safe Of
3. He also has a problem that even if I don't use this class He will also create an instance to occupy our memory This leads to his low efficiency
4. A single instance of this version cannot have other instance variables , Otherwise, there will still be nonlinear safety problems ( The non thread safety problem is A thread caused dirty reading of data by modifying an instance variable )

Log in and copy

// Starving model 
class Singleton{
    // 1、 Use  static  Create an instance , And instantiate it immediately ,
    private  static  Singleton instance = new Singleton();
    // 2、 To prevent programmers from being careless elsewhere new This  Singleton, You need to set the constructor of this class to  private
    private Singleton(){};
    //3、 Provide a method , Let the outside get the only instance .
    public static Singleton getInstance(){
        return instance;
    }

}

     

      
1.
      
2.
      
3.
      
4.
      
5.
      
6.
      
7.
      
8.
      
9.
      
10.
      
11.
      
12.
     

analysis :

(1) Why thread safe ?

​ Because it is initialized when the class is loaded ( The first 2 That's ok ), Only one copy. , So it's thread safe .

(2) shortcoming

① Not yet used , It wastes memory space .

②new object ( Class loading is not performed , Will execute first , Then execute the member variable + Instance code block + Construction method ), May throw an exception , That is, you haven't called getInstance, An exception is thrown when the class is loaded , Then call later getInstance When the method is used , There will be problems .

---

2. The sluggard model ( Thread unsafe )

1. The lazy man model improves the shortcomings of the hungry man model It only lets this class instantiate an object when it is used And after that, you can only get this object
2. So we generally think that the lazy man mode is better than the hungry man mode More efficient
3. however Lazy mode also has disadvantages. Its thread is not safe This is in It can be optimized

Because I'm lazy , You make me work , I just started , Otherwise I won't take the initiative ~

​ Talk is talk ： When the class loading , Don't rush to initialize the object , First call , Initialize object , Call again later , Directly return the first created object .

Log in and copy

// The singleton pattern  -  The sluggard model 
class Singleton2{
    //1、 Instead of initializing the instance immediately 
    private static Singleton2 instance;//  The default value is ：Null
    //2、 Set the construction method to  private
    private Singleton2(){};
    //3、 Provide a public method , To get this   The only instance of the singleton pattern 
    public static Singleton2 getInstance(){
        //  Only when we actually use this example , Will actually create this instance 
        if(instance == null){
            instance = new Singleton2();
        }
        return instance;
    }
}

public class Test20 {
    public static void main(String[] args) {
        Singleton2 instance = Singleton2.getInstance();
    }
}

     

      
1.
      
2.
      
3.
      
4.
      
5.
      
6.
      
7.
      
8.
      
9.
      
10.
      
11.
      
12.
      
13.
      
14.
      
15.
      
16.
      
17.
      
18.
      
19.
      
20.
      
21.
     

analysis :

Why thread is not safe ?

stay getInstance() In the method , There are three lines in all Java Code .

And among them instance = new Singleton() Will be decomposed into three lines of bytecode instructions , It is equivalent to concurrent and parallel operations on multiple rows of shared variables , So it's not thread safe .

---

difference ：

Starving model and The sluggard model The only difference ：

lie in The timing of creating an instance is different .

Starving model yes When the class loading , establish .
The sluggard model yes First use , establish .

So the lazy mode is lazier , When not in use , Do not create ; When you use it , Create again .
The purpose of this , Namely Save resources .

---

In fact, in many other computer scenes , This situation will also be involved .

A typical case ：

notepad Such a program （ Notepad software ）, It's very slow to open large files .
If , You have to open a 1G Size file , here notepad will Try this 1 G Of Everything is read into memory .
take 1G The amount of data Deposit in Memory , Obviously Very slow Of .
Whether you want to or not , All for you .
This is it. Starving model .

The problem comes with ： These data , Can we really use it all ？ Display is unlikely .
Therefore, a lot of resources will be wasted .
 
Like some other programs , When you open a large file, there is optimization .
Suppose it's also open 1G The file of , But only load the part that can be displayed in this screen first .
See where , Where to load . This will not waste space
This is it. The sluggard model

---

Thread safe singleton mode

1. The sluggard model +synchronized Static synchronization method ( Thread safe but inefficient )

When it comes to making a code thread safe , We naturally think of locking ！
But the problem is ： Where is the right place to lock ？
In fact, observation is also very good , take if Statement execution to Lock , Make its two operations atomic .
To put it bluntly ： Namely if sentence Pack it up “ all in one ”, Just like the previous analysis count++ equally .
Consistency execution finished .

Lock range Be sure to include if sentence ！！！
Otherwise it won't work , It looks like this ！

Originally, we wanted to read and Write operation , Pack it as a whole ,
But now it's just Lock the write operation , At this time, it's like not locking equally , There is no difference .

Please pay attention ！ Not in the code synchronized, It must be thread safe .
It needs to see synchronized Location of addition , Be right, too .
therefore synchronized Where to write . You can't do it casually .
 
Come back to , Let's take another look synchronized The object of the lock writes what we should .

Log in and copy

// The singleton pattern  -  The sluggard model 
class Singleton2{
    //1、 Instead of initializing the instance immediately 
    private static volatile Singleton2  instance;//  The default value is ：Null
    //2、 Set the construction method to  private
    private Singleton2(){};
    //3、 Provide a public method , To get this   The only instance of the singleton pattern 
    public static Singleton2 getInstance(){
            //  Only when we actually use this example , Will actually create this instance 
            synchronized(Singleton2.class){
                if(instance == null){
                    instance = new Singleton2();
                }
            }
        return instance;
    }
}

     

      
1.
      
2.
      
3.
      
4.
      
5.
      
6.
      
7.
      
8.
      
9.
      
10.
      
11.
      
12.
      
13.
      
14.
      
15.
      
16.
      
17.
     

Although we do through the above locking operation , It's solved if sentence The atomicity of .

however ！ Such a program , There are still several problems ！

1. Code execution efficiency

2、 Instruction reordering
Although other threads call again When a singleton thread , Also added synchronized Of .
Slow down the cycle speed , So as to ensure Memory visibility .
however ！ There's another problem , Look at the following .

here , We just completed a thread safe singleton mode - The sluggard model
1、 Lock in the right position
2、 double if determine
3、volatile keyword

---

2. The sluggard model + Second judgment ( Double check lock , Thread safe and efficient )

usage ：

• Double check : Two if.
• lock : synchronized
• Pay attention to using static variables ( quote ) Use volatile.

Log in and copy

class Singleton {
    private static volatile Singleton instance = null;
    private Singleton() {}
    public static Singleton getInstance() { 
        if (instance == null) {  // The first 5 That's ok 
            synchronized (Singleton.class) { // The first 6 That's ok 
                if (instance == null) {  // The first 7 That's ok 
                    instance = new Singleton(); // The first 8 That's ok 
                } 
        }
        return instance; // The first 9 That's ok 
    }
}

     

      
1.
      
2.
      
3.
      
4.
      
5.
      
6.
      
7.
      
8.
      
9.
      
10.
      
11.
      
12.
      
13.
     

analysis :

• ① Before object initialization , Multithreaded call getInstance(), Need to ensure thread safety , I.e. implementation of the 5,6,7,8 That's ok .
• ② After object initialization , Only execute if Judgement and return sentence , That is, only execute the 5,9 That's ok .

​ ② Obvious ratio ① There are many, many cases of implementation , So consider not locking , Increase of efficiency .

​ ② No need to lock , have access to volatile Guaranteed visibility .

namely :

​ The first 5 That's ok : After initialization , No need to lock , Use volatile Modifying variables , Guaranteed visibility , It can meet thread safety , The code line itself is atomic . It can execute in parallel , Improved efficiency .

​ The first 6 That's ok : When initialization is not completed , Creating objects requires locking to ensure thread safety .

​ The first 7 That's ok : Threads that fail to compete for locks , Synchronized code blocks are also executed , It needs to be judged again , Make sure to initialize only once .

​ The first 9 That's ok : The quotation uses volatile keyword , There is also the establishment of memory barriers , The function of prohibiting instruction reordering (new Decomposed three instructions : Allocate memory space , Initialize object , Assign a value to a variable )

---