Foundation of JUC concurrent programming (8) -- read write lock

Read-write lock （ a key ）

Pessimistic lock and optimistic lock

Pessimistic locks do not support concurrent operations , Efficiency is very low .

Optimistic locking is achieved by adding a version number to the operation resource , Multiple threads can operate at the same time , Who submits first , Version number update , Subsequent threads cannot commit .

Table locks 、 Row lock

When the operation resource is a data table , Table lock directly locks a table , Even if only one row of data is operated .

Row lock locks one row , Other lines can be operated by other threads , However, the row lock may be deadlocked .

Read the lock 、 Write lock

Read the lock ： Shared lock , There's a deadlock

Write lock ： An exclusive lock , There's a deadlock

Knowledge supplement ： Memory visibility issues

Small example ：

/** *  Example of memory visibility of variables  * * @author star */
public class VolatileExample {
     

    /** * main  Method as a main thread  */
    public static void main(String[] args) {
     
        MyThread myThread = new MyThread();
        //  Open thread 
        myThread.start();

        //  Main thread execution 
        for (; ; ) {
     
            if (myThread.isFlag()) {
     
                System.out.println(" The main thread accesses  flag  Variable ");
            }
        }
    }

}

/** *  Child thread class  */
class MyThread extends Thread {
     

    private boolean flag = false;

    @Override
    public void run() {
     
        try {
     
            Thread.sleep(1000);
        } catch (InterruptedException e) {
     
            e.printStackTrace();
        }
        //  Change the value of the variable 
        flag = true;
        System.out.println("flag = " + flag);
    }

    public boolean isFlag() {
     
        return flag;
    }

    public void setFlag(boolean flag) {
     
        this.flag = flag;
    }
}

The console never outputs The main thread accesses flag Variable this sentence , Because the main thread reads flag The value is false, But in MyThread In the thread , It is clear that flag The value is set to true, Why can't I read it ？ This involves Java Knowledge of memory models , Memory visibility is involved .

Java Memory model , abbreviation JMM, yes Java Virtual machine defined , It is an underlying model mechanism of concurrent programming .

In general JMM The abstract relationship between thread and main memory is defined ： Shared variables between threads are stored in Main memory in , Each thread has a private Local memory , The thread is stored in local memory to read / Write Share a copy of the variable .

Maybe the thread changed the copy value in local memory , however JMM Not updated to main memory in time , What causes other threads to get is still the previous value , Or the thread failed to synchronize the latest value in the main memory to the working memory , This will lead to such visibility problems .

Memory visibility It refers to when a thread modifies the value of a variable , Other threads can always know the change of this variable . in other words , If the thread A Modified shared variables V Value , So thread B In the use of V The value of , Can read immediately V The latest value of .

Two operations to ensure memory visibility ：

• Lock

  The principle of locking is, for example, when a thread obtains a lock , Will empty local memory , Then copy the latest shared variable from main memory , Execute code , Refresh the value of shared variables in main memory after execution , Release the lock .

• volatile keyword

  Use volatile After modifying shared variables , When each thread wants to manipulate a variable, it copies the variable from main memory to local memory as a copy , When the thread operates a copy of the variable and writes it back to main memory , Will pass CPU Bus sniffer mechanism Tell other threads that the copy of the variable has expired , Need to read from main memory again .

  volatile It ensures the visibility of different threads to shared variable operations , In other words, a thread has modified volatile Decorated variable , When the modified variable is written back to main memory , Other threads can see the latest value immediately .

The use of read-write lock is , When the writing thread is not finished , There may be threads reading , So add a write lock , Release the lock after writing , Then you can read , Plus read lock , After reading it, you can continue to write it .

At this time, someone will ask , Then this lock and volatile What's the difference between keywords , Don't you make the shared variables visible to other threads immediately when they are updated ？

My understanding is that ,volatile Just let the working memory and main memory be updated immediately after the shared variables are updated , But before that, the reading thread may read first , So you need a lock , If there is no volatile Even if you finish writing , Maybe what you read is not the updated value .

The evolution of read-write locks ：

Degradation of read-write lock

Demote write lock to read lock

Blocking queues

Threads 1 Put elements in the queue , Threads 2 Take elements from it

The queue is full Then the thread is blocked , Get thread blocking when empty

Its advantage is that the thread operation of this queue is fully automatic , Don't worry about yourself when you need to block and wake up

Blocking queue classification

• ArrayBlockingQueue

  Bounded blocking queue with array structure

• LinkedBlockingQueue

  The list structure consists of （ The default size is integer.MAX_VALUE） Blocking queues

• DelayQueue

  The use of priority queue to achieve unbounded delay blocking queue

The core approach