Shulou(Shulou.com)06/02 Report--

What is the definition and implementation principle of volatile in Java concurrent programming? I believe many inexperienced people don't know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Preface

Java code becomes Java bytecode after compilation, bytecode is loaded into JVM by class loader, and JVM executes bytes

Code, which eventually needs to be converted into assembly instructions to be executed on CPU. The concurrency mechanism used in Java depends on the implementation of JVM and

Instructions from CPU.

2.1Application of volatile

Both synchronized and volatile play important roles in multithreaded concurrent programming, and volatile is lightweight.

Synchronized, which ensures "visibility" of shared variables in multiprocessor development. Visibility means that when a thread

When you modify a shared variable, another thread can read the modified value. If the volatile variable modifier is used properly

It is cheaper to use and execute than synchronized because it does not cause thread context switching and scheduling.

The definition and implementation principle of 1.volatile

Volatile is defined in the third edition of the Java language specification as follows: the Java programming language allows threads to access shared variables in order to

To ensure that the shared variable is updated accurately and consistently, the thread should ensure that the variable is obtained separately through an exclusive lock. Java language

Volatile is provided, which is more convenient than locks in some cases. If a field is declared as volatile,Java thread memory

The model ensures that all threads see that the value of this variable is consistent.

How does volatile ensure visibility? Let's get the JIT compiler generated by the X86 processor through the tool

Assemble instructions to see what CPU does when writing to volatile.

The Java code is as follows.

Instance = new Singleton (); / / instance is the volatile variable

Convert it to assembly code, as follows.

0x01a3de1d: movb $0 × 0,0 × 1104800 (% esi); 0x01a3de24: lock addl $0 × 0, (% esp)

Shared variables modified by volatile variables will have a second line of assembly code when writing, by checking the IA-32 shelf

According to the software developer's manual, instructions with the Lock prefix can cause two things in a multi-core processor.

1) write the data of the current processor cache row back to system memory.

2) this write-back operation invalidates the data that has the memory address cached in other CPU.

In order to improve the processing speed, the processor does not communicate directly with the memory, but first reads the data from the system memory to the inside.

Do the operation after caching (L1 and L2 or others), but you don't know when it will be written to memory. If the volatile is declared to

Variable, JVM sends an instruction with a Lock prefix to the processor, passing the data of the cache line in which the variable is located

Write back to system memory. However, even if it is written back to memory, if the value cached by other processors is still old, then perform a computational operation.

If you do it, there will be problems. Therefore, under multiprocessors, in order to ensure that the cache of each processor is consistent, a cache is implemented.

In the sex protocol, each processor checks whether its own cached value has expired by sniffing the data propagated on the bus, when

When the processor finds that the memory address corresponding to its cache line has been modified, it will set the cache line of the current processor to invalid.

When the processor modifies the data, it will re-read the data from the system memory to the processor cache

In.

Let's explain two implementation principles of volatile in detail.

1) the Lock prefix instruction causes the processor cache to write back to memory. The Lock prefix instruction causes the sound during the execution of the instruction

The LOCK# signal of the speech processor. In a multiprocessor environment, the LOCK# signal ensures that during the assertion of the signal, the processor can

Monopolize any shared memory (because it locks the bus so that other CPU cannot access the bus, which means that it cannot access the system

Save). However, in recent processors, LOCK# signals generally do not lock the bus, but lock the cache.

The cost of locking bus is relatively high. The impact of locking operations on processor caching is described in detail in section 8.1.4, for Intel486 and

The Pentium processor always declares the LOCK# signal on the bus during the lock operation. But in P6 and the current processor, if

If the accessed memory area is already cached inside the processor, the LOCK# signal is not declared. Instead, it locks the memory area.

Domain cache and write back to memory, and use cache consistency mechanism to ensure atomicity of modification, this operation is called "cache lock"

The cache consistency mechanism prevents simultaneous modification of memory region data cached by more than two processors (to be clear

It is the cache consistency mechanism that ensures that when one cache is locked, other processors with the same cache cannot be modified.

2) the cache of one processor is written back to memory, which will invalidate the cache of other processors. IA-32 processor and Intel 64

The processor uses the MESI (modify, exclusive, shared, invalid) control protocol to maintain consistency between the internal cache and other processor caches.

Sex. When operating in a multi-core processor system, the IA-32 and Intel 64 processors can sniff other processors to access the system

Memory and their internal cache. The processor uses sniffing technology to ensure its internal cache, system memory, and other processor's

The cached data is consistent on the bus. For example, in Pentium and P6 family processors, if you sniff a process

Device to detect that other processors intend to write the memory address, and this address is currently in a shared state, so the processing being sniffed

The device invalidates its cache line and forces the cache line fill the next time the same memory address is accessed.

After reading the above, have you mastered the definition and implementation principle of volatile in Java concurrent programming? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.