Knowledge points about jmm and DCL

 

Link Summary In jmm:
The working memory corresponds to the high-speed cache of each processor in the multi-core processor. The primary memory corresponds to the memory.
The relationship between the working memory and the primary memory is like the relationship between the distributed cache and the client. Heap sharing is the basis for thread communication in Java.
The variable in the working memory is the copy of the variable in the primary memory.
Variables in the working memory can be viewed by other working memory only when they are submitted to the primary memory.

 

Volatile:

 

Volatile principle: directly access the variables in the primary memory without using the working memory. The applicable scenarios are variable variables that change frequently. This ensures that the latest content is read each time. Of course, performance is sacrificed.
Volatile also prevents JVM from optimizing code (reorder)
The difference between final and volatile is that final does not change after the constructor is executed. This does not provide the opportunity to modify multiple threads. Of course, it is thread security. However, volatile provides the opportunity to modify multiple threads. However, you can directly operate on the primary storage.
Therefore, be sure to associate final with the thread. Instead of how to improve performance.

 

 

 

Synchronized principle.
Modifier:
Synchronized (OBJ ){
......
}
OBJ can be this, an attribute of the object.
OBJ is also called Monitor.
Note that synchronized has the same principle of modifying the block method. The default value of this is monitor.
Generally, monitor is regarded as lock. The principle is that after Synchronized obtains the monitor object, it will lock the monitor. Monitor is not a lock. It is usually easy to define the OBJ name in the program as ** lock. This is not appropriate. But it does not affect usage.
After locking the monitor, other threads must wait for the last operation to unlock the monitor to access the method or code block. After unlocking, other threads can lock the monitor and further access it.
When synchronzied modifies the static method, the locked object is object. Class, instead of this.

 

DCL generation and solution:
First, the reason why DCL is generated is that delay loading is used in the Singleton.
Even if volatile is used for objects, JVM will still reorder the volatile and non-volatile attributes. It is estimated that the reorder issue will be avoided unless all of them are volatile attributes. As long as there is a reorder, it may lead to: "allow objects to point the reference of shared variables to partially constructed objects before the constructor is called up. Although the object is not fully instantiated, but it is no longer null ".
Therefore, if you do not need to delay loading for a single instance, you can achieve this:
Class Singleton {
Private vector V;
Private Boolean inuse;
// Do not perform delayed loading to avoid DCL.
Private Static Singleton instance = new Singleton ();

Private Singleton ()
{
V = new vector ();
Inuse = true;
//...
}

Public static Singleton getinstance ()
{
Return instance;
}
}

In addition, you need to perform the single-instance loading and delayed loading as follows: Internal classes can be loaded only when being referenced.
Public class Foo {
// Static internal class. This class will be loaded only when there is a reference
Private Static class lazyfoo {
Public static Foo = new Foo ();
}

Public static Foo getinstance (){
Return lazyfoo. Foo;
}
}
If you want to use a single instance, delay, and multi-threaded access:
Public class Foo {
Private Static class lazyfoo {
Public static Foo = new Foo ();
}

Public static synchronized Foo getinstance (){
Return lazyfoo. Foo;
}
}