What is the thread safety
When multiple threads access a class, which uses scheduling environment or how these threads are alternately performed regardless of the runtime, and does not require any additional synchronization or coordination, this class can show the correct behavior in the calling code, then call this class thread safe. ---- "Concurrent Programming combat."
What is thread safe
Multi-threaded concurrent access, can not get the correct result.
result:
Causes of insecurity thread:
++ num not atomic operations, is split into several steps, in the case of concurrent execution of multiple threads, as cpu scheduling, multi-thread switching express, it is possible to read the two are the same timing num same value, then it +1 operation, resulting thread safety.
Atomic operations
What is atomicity operation
- One operation or more operations either all execution and implementation process will not be interrupted by any factor, or to not execute. Popular speak: the success of the operation to succeed together, we fail to fail together.
How to become a non-atomic operation atomicity
- synchronize keywords, so that the operation is atomic
The volatile keyword only guarantee visibility, does not guarantee atomicity
In-depth understanding of synchronized
- Built-in locks: Each java object can be used as a synchronization lock to achieve, these locks are called built-in lock. When a thread enters a synchronized block or method of automatically acquire the lock, when you exit the synchronized block or method releases the lock. The only way to get the lock is built into this block or a sync lock protection method.
- Mutex: built-in lock is a mutex, which is meant at most only one thread can acquire the lock, when the thread A thread B attempts to get hold of the built-in lock, thread A must wait or block until the thread B release the lock, if thread B does not release the lock, then A thread will wait forever.
- Modification of the conventional method: Example locked object
- Modified static method: lock the entire class
- Modified code block: synchronized lock object (Lock) i.e., the rear brackets synchronized content
volatile keywords and their usage scenarios
- And can only modify variables
- Ensure that the variable visibility, volatile keyword only guarantee visibility, does not guarantee atomicity
- Prohibit instruction reordering
- A, B two threads simultaneously read volatile keyword modified the object, then A read, modify the value of the variable, the value of the modified thread to B, it is visible
scenes to be used:
- As a thread switch
- Single embodiment, the modified object instance, prohibit instruction reordering
Singleton thread safety
Hungry man style - itself thread-safe
- When the class is loaded, it has been instantiated, either after use to do. If the class comparison of total memory, not any later use, wasted resources.
result:
Lazy style - simple wording not thread-safe
- When needed and then instantiate
result:
Lazy man - made thread-safe
result:
How to avoid thread-safety issues
Causes of thread safety issues
- Multithreaded environment
- Multiple threads operating the same shared resources
- Non-atomic operation performed to the shared resource
How to avoid
- Multithreaded environment - will change the single-threaded multi-threaded (necessary code lock access)
- A plurality of threads operate in the same shared resource - not shared resource (the ThreadLocal, not shared, the operation of the stateless, immutable)
- Were non-atomic operation on the shared resource - the non-atomic operation into atomic operations (lock, built using JDK classes atomic operation, concurrent corresponding tools provided JUC)
Cause at any point in the three-point break
Source address: https: //github.com/woxbwo/is-concurrent
carry out! ! !