Home PC Games Linux Windows Database Network Programming Server Mobile  
           
  Home \ Programming \ The Concept and Semantics of Java Memory Model     - Nginx Performance Tuning Guidelines (Server)

- Linux, Google Test (GTest) test environment to build step (Linux)

- Linux security concerns again (Linux)

- Loop arrays in C language is not easy to find a bug (Programming)

- Linux Getting Started tutorial: Ubuntu 14.04 in the installation Sogou Pinyin (Linux)

- Linux see whether there is a hacker program (Linux)

- Workaround CentOS error message during compilation PHP5 common (Linux)

- RHEL6.5 replace local YUM source (Linux)

- Iptables small summary (Linux)

- How to create a binary distribution with Bash (Linux)

- Mongo-connector integrated MongoD to achieve incremental Solr index (Server)

- Python method to traverse folders and file read and write (Programming)

- grep command usage (Linux)

- Zabbix monitoring disk IO status (Server)

- Linux screen commonly commands (Linux)

- Using BBED repair ORA-01190 error (Database)

- E: Sub-process / usr / bin / dpkg returned an error code (1) error solution (Linux)

- Oracle RMAN-06023 and ORA-19693 errors (Database)

- Java inner classes (Programming)

- Fragment Android developers learning to resolve (Programming)

 
         
  The Concept and Semantics of Java Memory Model
     
  Add Date : 2017-08-31      
         
         
         
  JDK5 introduced the new JMM specification: JSR-133, introduced the concept of happen-before / visibility, such as synchronized / volatile / final keywords such as the semantic definition. Resolved: Final variables thread initialization in the constructor of the safety and volatile variables and no-volatile variables between the reordering problem.
Why Memory Model

In a multi-threaded scene, thread1 to modify a variable, thread2 to read this variable, which may occur during the order of the implementation of the problem (because the compiler optimization instruction, the processor reorder instruction, write data cache is not updated to Main memory). How to ensure that the variable is to read the thread2 Thread1 want to amend the variables?
 
Memory Model describes the variables in the program and their relationship in registers, cache, and memory. That is, in the absence of Momory Model, can not guarantee the multithreading environment variable call order, with the Memory Model specific keywords corresponding to the semantic definition (such as the synchronized / volatile / final), you can use these keywords Ensure that the program is in accordance with the desired logic in a multi-threaded environment to the correct implementation.
Old JMM problem

Issue # 1: Immutable Objects are not immutable
 
Immutable objects: All fields of an object must be final, and must be a primitive type or a reference to an immutable object. For example, the String object is immutable and semantically should not require synchronization, but the fact is that there may be competing conditions in a multithreaded scenario.
 
@ JKD1.4
Class String
{
     Static final char [] charArray;
     Static int length;
     Static int offset; / / that the beginning of the string position
}}
 CharArray array and length, offset can be shared in multiple String / StringBuffer. For example String.substring () is to share the original String charArray.

String s1 = "/ usr / tmp";
String s2 = s1.substring (4); // contains "/ tmp"
In the old JMM, there is no synchronization. Initialize s1, the object constructor will length / offset initialized to 0, this time other threads can access these values (this time using substring obvious problem), then the String constructor for the length / offset assignment as needed value. The new JMM model solves the thread-safety problem of finalizing a final variable in the constructor, which means that the final variable is not allowed to be visible to other threads until it is initialized (before the constructor completes execution).

 
Issue # 2: Re-ordering volatile and non-volatile variables
 
Volatile variables in the old JMM only one semantics: For a volatile variable read, can always see the other arbitrary thread on the volatile variables of the last write. That is, writes to volatile variables are happends-before other threads read them.
 
In the old JMM, although reordering between volatile variables is not allowed, the reordering of volatile variables with other normal variables is allowed. This causes a problem in scenarios where volatile variables are flagged.
 
Map configOptions;
Char [] configText;
Volatile boolean initialized = false;
.
// In thread A
ConfigOptions = new HashMap ();
ConfigText = readConfigFile (fileName);
ProcessConfigOptions (configText, configOptions);
Initialized = true;
.
// In thread B
While (! Initialized)
  Sleep ();
// use configOptions, in the old JMM, there is no guarantee that configOptions have been initialized, because the order of variables may have been rearranged.
 

The new JMM model solves this problem by introducing a new semantics: volatile variables can not be rearranged with non-volatile variables.
The new JMM

Visibility
When ThreadA implementation val = 1, other threads can see how to ensure that the implementation of ThreadA results (that variable at this time on the other thread Visibility)? JMM specification of certain definitions (volatile / synchronized / final) to ensure that this matter.
 
Synchronization and Visibility
Synchronization not only has access to a critical area lock semantics, but also has the memory visibility (memory visibility) significance. When you leave the synchronized block, the cache must flush to main memory. When you enter the synchronized block, the cache is invalid, and subsequent read operations must be read to main memory. That is, the variables inside the synchronized block write operation is visible to other threads (visible)!
 
Volatile
The new JMM enhances the memory semantics of volatile and prohibits rearrangement with normal variables. That is, threadA writes to a volatile variable, threadB reads that variable. Then all the variables visible to A must be visible to B at the same time.
 
Happens-before
Ordinary multithreading If there is no data sharing and interaction, the instructions may be reordered for optimization reasons, will not be affected. If there is data between the competing threads, you need to use synchronized (Moniter) / volatile, etc. to ensure that the order of the implementation of the order. JMM defines a sort called "happens-before", which uses the concept of JMM to explain what memory visibility is. If the result of one operation A is visible to the other operation B, then A happends-before B.
* A thread in front of the operation happends-before the next operation.
* On the monitor unlock happends-before follow-up of the lock operation.
* Write to the volatile variable happends-before subsequent reads.
* Thread.start () calls the operation happends-before thread-internal operations.
* All operations of the thread are happends-before the subsequent thread join ().
 
Data races - data competition
There is data competition, indicating that the program did not make good synchronization, did not handle the happends-before relationship.
 
 
Initialization of the final variable security
 
Objects are only visible to other threads after their initial initialization. This means that initialization of the final variable can be thread-safe without the use of synchronization. In this way, the final variable to achieve the true sense of the final (that is, not - can - change), and not in the initialization process, the multithreading appears to change.
 
Class A
{
     Final Map < String, String> map = null;
     Public void A ()
     {
          Map = new HashMap < String, String> ();
          Map.put ( "key1", "value1");
     }}
}}
 

Other threads Before referencing an object, JMM guarantees that A's final variable has been fully initialized by its constructor. That is, the final initialization of the variable happends-before other threads reference the object. That is, the initialization of the final variable in the constructor is thread-safe.
     
         
         
         
  More:      
 
- Linux / UNIX: Use the dd command to create a 1GB size binary (Linux)
- Is Linux the most secure operating system (Linux)
- ImportTsv-HBase data import tool (Database)
- PostgreSQL 9.4.3 Installation and Configuration under CentOS 6.5 (Database)
- Get and Post requests Comments (Linux)
- ElasticSearch basic usage and cluster structures (Server)
- To install Ganglia (Linux)
- OGG-01496 OGG-01031 Error Resolution (Database)
- Experience RHEL7 new features (Linux)
- SUSE Linux install Oracle 10g and problem solving (Linux)
- Linux system security knowledge (Linux)
- CentOS 6 kernel upgrade to Kernel 3.x (Linux)
- Oracle Migration partition table (Database)
- Debian installation (Linux)
- Python Multithreaded Programming (Programming)
- Linux Basics Tutorial: create your own Vim IDE (Linux)
- Report generation CPU, memory, and input and output ports with the sar command (Linux)
- Using Linux / Unix Text processing (Linux)
- Execute command sentence can result in equipment permanently bricked in Linux laptop (Linux)
- ethtool command Detailed (Linux)
     
           
     
  CopyRight 2002-2022 newfreesoft.com, All Rights Reserved.