Java Concurrency Programming (iii) Concept INTRODUCTION

Threads and locks must be used correctly when building robust concurrent programs. But it's just some mechanism. The core of writing thread-safe code is to manage state access operations, especially for shared and variable (Mutable) state access.

The state of an object refers to the data stored in a state variable, such as an instance or a static domain.

The state of the object may include other dependent objects for the domain . For example, the state of a hashmap is not only the HashMap object itself, but is also stored in many Map.entry objects.

"Sharing" means that variables can be accessed concurrently by multiple threads, while "mutable" means that the value of a variable can change over its lifetime.

Thread security is how to prevent uncontrolled concurrent access on data.

Whether an object needs to be thread-safe depends on whether it is accessed by multiple threads.

To make an object thread-safe, you need to use a synchronization mechanism to coordinate access to the mutable state of the object. Failure to achieve synergies can lead to data corruption and other results that should not occur.

The synchronization mechanism for variable access with multiple threads is mainly:

1. Keyword synchronized

2. Keyword volatile

3. explicit lock (Explicit Lock)

4. Atomic Variables

The methods of accessing a mutable state variable in collaborative multithreading are:

1. Do not share this state variable between threads

2. Modify the state variable to a variable that is immutable

3. Use synchronization when accessing state variables

What is thread safety?

A class is accessed in a multithreaded environment, and this class always shows the correct behavior, so it is called thread-safe.

The necessary synchronization mechanisms are often encapsulated in thread-safe classes, so the client does not need to take further action.

Stateless objects must be thread-safe.

Stateless can greatly reduce the complexity of the class in implementing thread security. Thread safety becomes a problem only when the class is saving some information.

Atomic Nature

Atomic operations are performed when an operation is executed by the CPU without fragmentation.

A typical non-atomic operation is a++, but it is actually a "read-modify-write" sequence of operations, and the resulting state depends on the previous state.

In concurrent programming, incorrect results due to improper execution order is a very important case, the race condition (Race Condition).

Race condition

A race condition occurs when the correctness of a calculation depends on the alternating execution timing of multiple threads. The most common race condition is the "check after execution (check-then-act)" operation, which determines the next action through a potentially defunct observation. For example, a singleton mode with lazy initialization.

Compound operations

To avoid the problem of race conditions, you must somehow prevent other threads from using this variable when a thread modifies the variable, ensuring that other threads can read and modify the state only after the modification operation is complete or later, rather than in the process of modifying the state. To ensure security, "check after execution" (such as lazy initialization) and read-modify-write (such as increment) must be atomic. We collectively refer to "post-inspection-first-execute" (such as deferred initialization) and read-modify-write as a composite operation: contains a set of operations that must be performed atomically to ensure thread safety.

Compound operations

Locking mechanism

Built-in lock

Synchronizing code blocks

Re-entry

Java Concurrency Programming (iii) Concept INTRODUCTION