1. Race Conditions
1.1 DefinitionsA race condition occurs when the correctness of a calculation depends on the alternating execution timing of multiple threads. In other words, the right result depends on luck. The most common type of race condition: Check the post-execution (check-then-act) operation, which determines the next action through a potentially defunct observation.
1.2 CharacteristicsAs with most concurrency errors, race conditions do not always produce errors, and some inappropriate execution timing is required.
1.3 Composite OperationTo ensure thread safety, actions such as "Check after execution" (such as lazy initialization) and read-modify-write are collectively called Composite Operations: contain a set of operations that must be performed atomically to ensure thread safety.
2 plus lock mechanism
2.1In the definition of thread security, it is required that the invariant conditions are not destroyed by the operation of multiple threads, regardless of the sequential or alternating mode of execution. When multiple variables are involved in an invariant condition, each variable is not independent of each other, but the value of one variable constrains the values of other variables. Therefore, when you update a variable, you need to update the other variables simultaneously in the same atomic operation.
2.2 Built-in lockJava provides a built-in locking mechanism to support atomicity: synchronous blocks of code (Synchronized block). A synchronous code block consists of two parts: an object reference as a lock, and a block of code that is protected by this lock. Each Java object can be used as a lock that implements synchronization, which is known as a built-in lock (intrinsic lock) or a monitor lock. The thread automatically obtains the lock before it enters the synchronization code block, and automatically releases the lock when exiting the synchronization code block, whether exiting through a normal control path or by throwing an exception from the code block. The only way to get a built-in lock is to enter a synchronous code block or method protected by this lock. Java's built-in lock is equivalent to a mutex (or mutex), which means that only one thread can hold this lock at most. When thread a attempts to acquire a lock held by thread B, thread A must wait or block until thread B releases the lock. If B never releases the lock, then a will always wait for it to continue.
2.3 Re-entry of the lockIf a thread attempts to acquire a lock that is already held by itself, the request succeeds. The re-entry further enhances the encapsulation of the locking behavior, thus simplifying the development of object-oriented concurrency code.
2.4 Using Locks to protect statusBecause locks enable their protected code paths to be accessed serially, some protocols can be constructed through locks to achieve exclusive access to shared state. As long as these protocols are always followed, you can ensure the consistency of the state.
2.5Bad concurrency (Poor Concurrency) applications: The number of simultaneous calls is limited not only by the available processing resources, but also by the structure of the application itself: Any request needs to wait for the previous request to complete. Ensure concurrent maintenance of thread safety: reduce the scope of the synchronized code block and try to avoid adding time-consuming operations such as IO to the synchronization code block.
Getting Started with Java Concurrency Programming (ii)
