Thread-safe implementation methods.
Let's say a few concepts:
1. Synchronization: Multi-threaded concurrent access to shared data, to ensure that the shared data at the same time can only be used by one (some, when using semaphores) thread.
2. Critical section: The code that accesses the critical resource in each process.
3. Critical resource: A resource that only one process is allowed to access at a time.
4. Semaphore: Equivalent to a counter, whenever a process uses a resource, semaphore-1; The process frees a resource, Semaphore +1, and the process cannot use the resource when the semaphore is 0 o'clock.
5. Mutex: With a semaphore size of 1, there are only 0 and 12 values.
One, mutual exclusion, synchronization, in Java implementation of the Synchronized keyword, java.util.concurrent package under the re-entry lock Reentrantlock.
The a.synchronized keyword, which takes advantage of the two bytecode instructions of Monitorenter and monitorexit, requires a reference type parameter that specifies the lock and unlock object, and for the same thread, the synchronization block is reentrant , other threads that attempt to acquire a lock are blocked until the hold lock thread has finished executing.
B. Functionally similar, but in code notation, it behaves as a mutex on the API level (lock () and unlock () with the try/finally statement block to complete), and adds advanced functionality:
① waits for interruptible, the thread holding the lock does not release the lock for a long time, and the waiting thread can choose to abandon the wait.
② can be re-constructed to set true on the method, implementing a fair lock, the default non-fair lock.
③ locks can bind multiple conditions, and a Reentrantlock object can bind multiple condition objects.
Note: jdk1.5 before the increase in the number of threads, synchronized performance decreased significantly, after 1.6 performance is approximately the same. The main problem is the performance problems caused by thread blocking and wakeup.
Second, non-blocking, synchronous, optimistic concurrency strategy, the first operation of shared variables, if no other thread contention, the operation succeeds, otherwise, the use of other compensation measures.
Dependencies and hardware: operation and conflict detection two steps are atomic.
java1.5 after operation has Sun.misc.unsafe class Compareandswapint () and Compareandswaplong () provided, this can only have bootstrap classloader load, Can be called indirectly with the Atomicint class in Juc.
However, the problem of "ABA" may occur, but it will not affect the results of the program generally.
Note: the "ABA" issue: The thread cannot judge when another thread changes and is changed back during the program's value.
Three, Volitile write tired, later will write again.
Java thread Synchronization