"Java Concurrency Programming Practical" reading notes 13--java memory model, reordering, Happens-before,

16th Chapter Java Memory model

Finally see the last chapter of the book, Hey, after the English version of the book to double-turn. This book avoids the underlying details of the Java memory Model (JMM) as much as possible, and focuses on high-level design issues, such as security releases, synchronization strategies, and so on. Their security comes from the JMM. This chapter describes the underlying requirements of the Java memory model and the guarantees provided.

16.1 What is the memory model and why does it need it

Memory model of the 16.1.1 platform

In a multi-processing architecture with shared memory, each processor has its own cache and is regularly reconciled to the memory. Different levels of cache consistency are provided in different processor architectures. It will take a lot of overhead to make sure that every processor knows what other processors are doing at any point in time. This information is unnecessary for most of the time, so the processor will appropriately loosen the storage consistency guarantee in exchange for performance gains. The memory model defined in the schema tells the application what guarantees it can get from the memory system, in addition to defining special instructions (called Memory fences or fences) that enable additional storage coordination guarantees when data is shared. To keep Java developers from having to care about the differences between memory models on different architectures,Java also provides its own memory model, and the JVM masks the difference between JMM and the underlying platform memory model by inserting a memory fence in place.

16.1.2 reordering

JMM can cause different threads to see the order of operations to be different, resulting in a lack of synchronization, to infer that the execution order of the operation will become more complex. Various operational delays or seemingly disorderly execution of the non-reason, can be attributed to the reordering.

Synchronization restricts the way that the compiler, the runtime, and the hardware reorder memory operations, so that reordering does not break the visibility guarantees provided by JMM.

16.1.3 Java Memory Model Introduction

JMM provides a partial-order relationship for all operations in the program, called Happens-before. To ensure that the thread executing action B sees the result of operation A, the happens-before relationship must be met between A and B. If there is a lack of happens-before relationships between the two operations, the JVM can reorder them arbitrarily.

16.1.4 with synchronization

Because Happens-before is a powerful sort feature, there are times when you can "use" the visibility properties of the existing synchronization mechanism (piggyback). This requires that the Happens-before program rules be combined with one of the other order rules to sort the access operations of an unlocked variable. This technique is very sensitive to the order of the statements and is therefore prone to error. It is an advanced technology and should only be used if you need to maximize the performance of certain classes, such as Reentrantlock.

The Futuretask protection method Abstractqueuedsynchronizer explains how to use this "with" technology.

16.2 Release

The 3rd chapter describes how to publish or improperly publish an object in a safe manner. The various security technologies described in it, their security comes from the assurance provided by JMM, and the real reason for incorrect publishing is the lack of a happens-before sort between "publishing a shared object" and "accessing the object from another thread."

16.2.1 unsafe release

If you cannot ensure that the operation that publishes the share reference executes before another line loads the shared reference, the write operation to the new object reference will be reordered with the write operations for each domain in the object. In this case, the other thread may see the most recent value of the object reference, but will also see that some or all of the object's state contains an invalid value, which is a partially constructed object. Delayed initialization of the error will result in an incorrect publication, as shown in program 16-3:

16.2.2 released securely

The security release common pattern introduced in the 3rd chapter ensures that the published object is visible to other threads because they guarantee that the operation of the publishing object will be performed before the thread that uses the object starts using the object's reference.

16.2.3 Safe Initialization mode

Sometimes it is necessary to postpone some high-overhead object initialization operations and initialize them only when they are used. In program listing 16-4, you can fix an issue in unsafelazyinitialization by declaring the GetResource method as synchronized. Because getinstance's code path is short, there is no fierce competition on safelazyinitialization if geiinstance is not frequently called by multiple threads.

As shown in program 16-5, the synchronization overhead resulting from each call to getinstance in Safelazyinitialization is avoided by early initialization. A specialized class was used to initialize the resource in the deferred initialization placeholder class mode in program 16-6. The JVM will defer initialization of Resourceholder until the class is started, and the resource is initialized with a static initialization, so no additional synchronization is required.

16.2.4 Double check Lock

DCL, which had been widely discarded, pass

16.3 Security during initialization

Summary:

Finally, the book is pretty much the same .... It's not easy to shout, but finally one more thing. This book probably now only understand about half, after all, only looked at once, poor translation quality for the book's reading added a lot of difficulty. In addition, the book theory is more than practice, the code practice is not much, the book has a lot of prerequisite knowledge is assumed you already know, so suitable for a certain basis of people to see. Later there is time to take a look at the English version, the most important thing is to use this knowledge in practice.

"Java Concurrency Programming Practical" reading notes 13--java memory model, reordering, Happens-before,