Ha ha, words are really like melons, beans get beans; There will always be a harvest to pay; Today boss sharing meeting just said that Java multithreading singleton use problem; I happened to see these contents these days, so I showed what I know at the meeting.

Went swimming in the evening, the swimming pool touched their own fat, ah, that call an exclamation ah; Too long do not exercise, as expected or easy to fat up ah; Then he swam hard in the pool and finally swam 1.5 kilometers, which was still a little short of his goal of 2 kilometers. In the future, I think we should all exercise, young man. After all, we are not married yet.

Let’s move on to chapter 3, which is a lot of stuff, but it’s also important. Now let’s look at the blackboard

The occurrence of thread safety problems: multiple threads concurrently access shared variables and shared resources

In order to ensure the security, the concurrent access of multi-thread to data is converted into serial access, so the lock arises at the historic moment

The code that the thread that holds the lock executes between the time it acquires the lock and the time it releases it is called a critical section

By how Java virtual machines implement locks:

Synchronized, unfair lock

Display locks (ReentrantLock, the implementation class of the Lock interface) and support fair and unfair locks

Locks are guaranteed atomicity through mutex (a lock can only be held by one thread at a time)

The acquisition of the lock implies the flushing of the processor cache, which causes the reader thread to synchronize the updates that the writer thread can make to the shared variable into the cache of the thread’s executing processor before executing the critical section code.

The release of the lock implies flushing the processor cache so that updates made by the writer thread to the shared variable can be accessed by one thread. This ensures visibility

Locking ensures order: a sequence of code executed in a critical section looks like it was executed exactly in source code order

Some concepts related to locking:

1. Reentrancy: Whether a thread can re-apply for a lock while it is holding it, if it is reentrant, otherwise it is non-reentrant

2, lock contention and call: fair lock, unfair lock

3. Lock granularity: The amount of shared data protected by a lock instance is called the lock granularity

The cost of locking and the problems it can cause:

Processor time overhead: lock application and release, context switch

Lock leak: The lock cannot be released so that other threads cannot acquire it

The underlying helper of thread synchronization: the memory barrier

Definition: a relatively low-level abstraction of a cross-processor architecture for a class of memory-only read and write operations

Insert between two instructions to prevent the compiler and processor from reordering to ensure order

By visibility: Loading barriers (flush processor cache), storage barriers (flush processor cache)

Sorted by order: Get barrier (insert barrier after read operation, forbid reordering between this read operation and any subsequent read/write operation), release barrier (insert barrier before write operation, forbid reordering between this write operation and any previous read/write operation)

Lightweight synchronization: volatile keyword

Indicates that the value of the variable being modified is subject to change, which means that all reads and writes to this variable must be read from cache or main memory to read the relatively new value of the variable. So volatile variables are not allocated by the compiler to registers for storage; All reads and writes to volatile variables are memory accesses

CAS and atomic manipulation:

Compare and swap is a name given to a processor instruction

CAS as an agent is equivalent to the following pseudocode:

Boolean compareAndSwap(variable v, objecta, object b){

F (a == v.get()){//check: checks whether the variable has been modified by another thread

v.set(b); //act: Updates variable values

return true;

}

return false; // The value of the variable has been modified by another thread, update failed

}

Atomic manipulation tools: Atomics are a group of utility classes based on CAS that guarantee atomicity and visibility for read modify-write update operations on shared variables

grouping

class

Basic data type

AtomicInteger, AtomicLong, AtomicBoolean

The array type

AtomicIntegerArray, AtomicLongArray, AtomicReferenceArray

Field updater

AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, AtomicReferenceFieldUpdater

applied

AtomicReference, AtomicStampedReference, AtomicMarkableReference

 

Object initialization security: revisit final and static

Class initialization in Java actually takes the lazy loading technique, meaning that after a class is loaded by the Java virtual machine, all static variable values of the class remain their default values until a thread accesses any static variable of the class for the first time

The static keyword only guarantees that the reader thread can read the initial value of the corresponding field, not the relative new value

Fields modified by the final keyword are initialized and read by other threads with the initial values of the fields