A preliminary understanding of java--the 13th chapter-Multithreading problems involved in the singleton pattern

One.

A singleton design pattern before talking, there is a part of the threading problem, so it's only half the story. Now describe it again.

The single case is divided into two forms, the lazy and the A hungry man.

Two.

Single example under multi-thread: a Hungry man

Lazy (lazy load single-case design mode)

When to use this object, then load it. This example is not ready to run, so to know.

Now you are ready to combine it into a multi-threaded basis to think of another part of the content, called in the multi-threaded case, there is no security risks.

if the getinstance () method is added to the Run method, it means that it will be executed by multithreading. When multithreading is performed, it involves sharing data (return s), which means that s is the shared data. Is there a security problem with it? It does not exist, because it has only one sentence, who comes back, is the same address, which does not exist. And here S has been final, fixed. This is not a very big problem, this is the A Hungry man style.

Now look at the lazy, if getinsatance put in the Run method, it means that can be executed by multithreading, it has no security implications?

We analyze, getinstance the statement in the method body as multithreaded run code, there is no shared data in the code? Yes, S is. Is there more than one statement of the operation S? Some.

There is no security problem, verify that you know, not ready to run through validation, direct analysis. The core is the problem of synchronization.

Thread 0 came in, S==null, contented. When thread 0 is switched off, the CPU execution is lost. Thread 1 came in and judged S==null? Met, thread 1 also switched away. (Is that possible?) Is possible, in line with the CPU at random switching) at this point, the 0 thread gets execution, executes, and now S has the object, returned. Immediately after, 1 thread obtains the execution right, does not have the judgment at all, the direct s=new single (), at this time two objects in the memory, cannot guarantee the object uniqueness, this is the question.

Problem analysis, now how to solve?

and synchronize. After adding the Synchronized keyword, the first thread comes in and S is empty. Even if the thread loses execution, the other thread cannot get in, wait until the thread wakes up to execute, resumes execution of the following statement, the new object, the return value, and finally exits. The second thread then comes in, a judgment s is not empty, nothing directly take this s on it. That will solve the problem. Thread safety issues, added a synchronized solved. It's not over, multi-threaded at the time of access, whenever the first thread comes in, it creates the object, and when the other threads come to take the object, they have to judge the lock. Before judging the s==null, you have to judge the lock more. Therefore, each time you take this object, you have to judge the lock (probably related to the implementation of the GetInstance method), the efficiency is low. Therefore, we say that synchronization solves thread safety problems, but reduces efficiency. To improve efficiency, we are ready to rewrite the code.

In the previous notation, this is written in parentheses in synchronized (), but not here. This is static and cannot be created by this class, only single.class.

Some people say getclass can not do, this can't. It's one thing to write This.getclass. Because the GetClass method is non-static.

Is there a difference between a synchronous code block and a sync function? No difference, after the thread comes in, still want to judge the lock, synchronized (Single.class).

Now modify the program,

The equivalent of the decision to determine the lock before the first step to determine the screening.

How do you understand it? The video is designed so that 0 threads and 1 threads are in front of the synchronized statement at the same time, after the if first judgment. 0 after the thread enters the synchronization code block, whether it is to maintain the CPU execution, or lose the CPU execution, 1 threads are not in. 0 after the thread has finished creating the object exits, the 1 thread comes in and is judged not to be eligible for a direct exit. and other threads after entering the getinstance function, because if the first judgment is not satisfied, do not have to execute the synchronization code block, improve efficiency. (Wouldn't there be more threads in front of synchronized ?) So the efficiency is not increased much)

This form of double judgment solves the problem of lazy-type security and efficiency. By contrast, writing a hungry man-style is better and easier.

During the interview, you will focus on the lazy type.

In general, the lock for a synchronization function is this, but the lock on the static function is not.

A preliminary understanding of java--the 13th chapter-Multithreading problems involved in the singleton pattern