Java multithreading under Race condition/synchronous/atomic operation problem __java

For synchronization, in addition to synchronization methods, you can also use synchronized code blocks, and sometimes synchronizing code blocks can result in better results than synchronization methods.
The fundamental purpose of the synchronization is to control the proper access to competitive resources, so as long as access to competitive resources is guaranteed to only one thread at a time, Java introduces a strategy for synchronizing code fast to improve performance


Java multithreading synchronization relies on the object lock mechanism, and the Synchronized keyword uses a blockade to achieve mutually exclusive access to shared resources.
To achieve synchronization of threads, these threads must compete for a unique, shared object lock.


1. HashMap is not read-write thread safe, only all read-only is thread-safe, hashmap can be used in concurrent read and write when the thread security problem, the general understanding of thread safety problems caused by data errors. While HashMap multi-threaded simultaneous read and write operations, you may suspend the program. In the case of high concurrency, a hashmap bucket becomes unpredictable when it has a large amount of data, and the action of the For loop fetching the object is read-write at the same time. The server's CPU may skyrocket and will not go down.


Workaround: If you know that you want to read and write a map in multi-threaded situations, it is recommended that you use a thread-safe concurrenthashmap implementation instead of HashMap. Concurrenthashmap can provide good concurrency without losing thread safety.

2. ArrayList is thread insecure, when multiple threads access the same ArrayList collection, if more than one thread modifies the ArrayList collection, the program must manually guarantee the synchronization of the collection.
Workaround: ArrayList and Vector are the two typical implementations of the list interface, vector collections are thread-safe, so the performance of vectors is lower than ArrayList performance.




1: What is atomic operation.
The smallest unit that the thread executes, and cannot be interrupted.


What is the 2:volatile principle?
General variables, in main memory and in the temporary memory of the thread is a cache/copy, in order to ensure that the data
Unified, requires synchronization, when synchronization is not complete, if other threads read the value on main memory will cause a different step exception.


Volatile is to tell the processor that the variable is unstable, not to cache the data in a thread's temporary memory, and to use data directly from the JVM's memory to avoid the synchronization steps.
3: Changes to the volatile variable data (not the value of the assignment), whether it can guarantee synchronization?


No. Even ++,--is not an atomic operation, because the CPU's thread switching, resulting in data is not controllable.


4: Then why use the volatile modifier.
Reading on volatile variables, and assigning values is guaranteed to be atomic




5: How to solve such a problem in the end.
The first: Using synchronous synchronized solution, which solves the problem, but also reduces the performance of the system.
The second: the use of atomic data atomic variables, this is the beginning of the JDK1.5 for the atomic solution, this solution is also a better solution now.




The realization principle of 6:atomic.
* 1 The variables in atomic are declared for the purpose of volatile variables, thus guaranteeing the storage and reading of variables
* is consistent, all from the same block of memory,
* 2) The atomic of the variable + + operation is encapsulated, provides the Getandincrement method,
*, and provides a Compareandset method to complete the lock and unlock operations on a single variable,
* Atomic Although solve the problem of synchronization, but there will be some loss of performance, but the impact is not big.





7:volatile whether the object instance can be decorated. Why object variable redistribution is also an atomic operation.


OK. The JVM guarantees that volatile reads must occur after the write operation, even if the sycnrhonized block is not used.


Because in the stack, an object variable stores an address that points to objects in the heap, so the operation is not responsible,


You can assume that assigning a value to an object is an atomic operation.


8: Why the variable assignment in Java is an atomic operation except for variables of type long and double.


Because the long and double types are greater than 32BIT, the JVM treats them as 2 atomic 32-bit values and needs to be assigned 2 times. So, not atomic operations.
If both hardware and software support 64BIT, long and double may be atomic operations.
In addition, object references are implemented using native pointers and are usually 32-bit. The operation of these 32-bit types is atomic.

Http://www.cnblogs.com/redcreen/archive/2011/03/29/1999032.html
Http://www.cnblogs.com/zhxxcq/archive/2012/04/18/2455916.htmlj
Http://www.knowsky.com/369575.html
Synchronized keyword http://baike.baidu.com/view/1207212.htm