并发、线程安全

喜欢ヅ旅行 2023-02-15 12:49 11阅读 0赞

### 目录 ###

*   *   *  概念、理论
         *   *  造成线程不安全的原因
             *  如何实现线程安全？
             *  互斥锁的特性
             *  锁的实现原理
             *  juc包简介
         *  实现线程安全的常用方式
         *   *  synchronized
             *   *  synchronized的用法
                 *  synchronized的实现原理
                 *  synchronized的4种锁状态及膨胀方向
             *  使用Lock接口
             *   *  ReentrantLock 可重入锁
                 *  ReentrantLock如何实现公平锁、非公平锁？
                 *  synchronized、ReentrantLock的比较
                 *  ReadWriteLock 读写锁
                 *  锁降级
                 *  AQS如何用int值表示读写状态
             *  StampedLock
             *  ThreadLocal
             *  volatile
             *  原子类
             *  并发容器
             *   *  Copy-On-Write集合容器CopyOnWriteArrayList、CopyOnWriteArraySet
                 *  ConcurrentHashMap、ConcurrentLinkedQueue
                 *  阻塞队列LinkedBlockingQueue、ArrayBlockingQueue
         *  并发工具类
         *   *  CountDownLatch
             *  CyclicBarrier 栅栏
             *  Semaphore 信号量
             *  Exchanger
         *  单例与线程安全
         *  锁的分类
         *  指令重排序
         *  数据同步接口

### 概念、理论 ###

并发：多个线程操作相同的资源，优点：效率高、资源利用率高，缺点：线程可能不安全、数据可能不一致，需要使用一些方式保证线程安全、数据一致

高并发：服务器能同时处理大量请求

线程安全：当多个线程访问某个类，不管采用何种调度方式、线程如何交替执行，这个类都能表现出正确的行为。

#### 造成线程不安全的原因 ####

*  存在共享资源
 *  多个线程同时操作同一共享资源，操做不具有原子性

#### 如何实现线程安全？ ####

*  使多线程不同时操作同一共享资源：eg. 只使用单线程、必要的部分加锁、使用juc的并发容器、并发工具类
 *  使对共享资源的操作具有原子性：eg.使用原子类
 *  不共享资源：eg. 使用ThreadLocal
 *  用final修饰共享资源，使之只读、不可修改

只要实现以上任意一点，即可实现线程安全

#### 互斥锁的特性 ####

*  互斥性：同一时刻只能有1个线程对这部分数据进行操作，互斥性也常叫做操作的原子性
 *  可见性：如果多个线程同时操作相同的数据（读、写），对数据做的修改能及时被其它线程观测到。可见性用happens-before原则保证

#### 锁的实现原理 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70]  
获取锁：把主内存中对应的共享资源读取到本地内存中，将主内存中的该部分共享资源置为无效  
释放锁：把本地内存中的资源刷到主内存中，作为共享资源，把本地内存中的该部分资源置为无效

#### juc包简介 ####

juc包提供了大量的支持并发的类，包括

*  线程池executor
 *  锁locks，locks包及juc下一些常用类CountDownLatch、Semaphore基于AQS实现。jdk将同步的通用操作封装在抽象类AbstractQueuedSynchronizer中，acquire()获取资源的独占权（获取锁），release()释放资源的独占权（释放锁）
 *  原子类atomic，atomic包基于CAS实现，实现了多线程下无锁操作
 *  并发容器（集合）collections
 *  并发工具类tools

### 实现线程安全的常用方式 ###

#### synchronized ####

##### synchronized的用法 #####

// 修饰普通方法
    public synchronized void a(){ 
    
    }
    
    // 修饰静态方法
    public static synchronized void b(){ 
    
    }
    
    
    public static Object lock = new Object();
    
    public void c(){ 
        // 修饰代码块。同步代码块，锁住一个对象
        synchronized (lock){ 
            
        }
    
    }

synchronized可以修饰方法、代码块，修饰的操作是原子性的，同一时刻只能有1个线程访问、执行

*  修饰普通方法，加的是对象锁，执行该方法时会自动锁住该方法所属的对象
 *  修饰静态方法，加的是类锁，执行该方法时会锁住所在类的class对象，即锁住该类所有实例
 *  修饰代码块，加的是对象锁，会锁住指定对象

如果要修饰方法，尽量用普通方法，因为静态方法因为会锁住类所有的实例，严重影响效率。

##### synchronized的实现原理 #####

synchronized使用对象作为锁，对象在内存的布局分为3部分：对象头、实例数据、对齐填充，对象头占64位

*  前32位是Mark Word，存储对象的hashCode、gc分代年龄、锁类型、锁标志位等信息
 *  后32位是类型指针，存储对象所属的类的元数据的引用，jvm通过类型指针确定此对象是哪个类的实例

Mark Work结构如下  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 1]  
每个对象都关联了一个Monitor（这也是为什么每个对象都可以作为锁的原因），锁的指针指向对象对应的Monitor，当某个线程持有锁时，Monitor处于锁定状态

##### synchronized的4种锁状态及膨胀方向 #####

无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁

*  无锁：没有线程要获取锁，未加锁
 *  偏向锁：大多数情况下，锁不存在多线程竞争，很多时候都是同一线程多次申请锁。偏向锁简化了线程再次申请锁的流程，减少了同一线程多次获取同一个锁的代价。偏向锁只适用于锁竞争不激烈的情况
 *  轻量级锁：适用于锁竞争一般的情况
 *  重量级锁：适用于锁竞争激烈的情况  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 2]

#### 使用Lock接口 ####

synchronized使用前自动加锁、使用完自动释放锁，很方便。synchronized是悲观锁的实现，每次操作共享资源前都要先加锁；以前是重量级锁，性能低，经过不断优化，量级轻了很多，性能和Lock相比差距不再很大。

Lock需要自己加锁、用完需要自己释放。Lock是乐观锁的实现，每次先操作共享资源，提交修改时再验证共享资源是否被其它线程修改过；Lock是轻量级锁，性能很高。

Lock接口有很多实现类，常用的有ReentrantLock 可重入锁、ReadWriteLock 读写锁，也可以自己实现Lock接口来实现自定义的锁。要注意是否可能发生异常，需不需要把释放锁放在finally中。

##### ReentrantLock 可重入锁 #####

重入：一个线程再次获取自己已持有的锁

public class Xxx{ 
        public final static ReentrantLock lock=new ReentrantLock(); //锁对象都可以加个final防止被修改
        //public final static ReentrantLock lock=new ReentrantLock(true); //可指定是否是公平锁，缺省时默认false
    
        public void a() { 
            lock.lock();  //获取锁，如果未获取到锁，会一直阻塞在这里
            // lock.tryLock(); //只尝试1次，如果未获取到锁，直接失败不执行后面的代码
            
            //.... //操作共享资源
            
            lock.unlock();  //释放锁
        }
        
        public void b() { 
            try { 
                lock.tryLock(30, TimeUnit.SECONDS);  //如果获取锁失败，会在指定时间内不停尝试。此句代码可能会抛出异常
                //.... //操作共享资源
            } catch (InterruptedException e) { 
                e.printStackTrace();
            }finally { 
                if (!lock.isFair()){ 
                    lock.unlock();  //如果获取到锁，最终要释放锁
                }
            }
        }
    
        public void c() { 
            lock.lock();
            try { 
                //.... //操作共享资源
            } catch (Exception e) { 
                e.printStackTrace();
            }finally { 
                lock.unlock();  //如果操作共享资源时可能发生异常，最终要释放锁
            }
        }
        
    }

##### ReentrantLock如何实现公平锁、非公平锁？ #####

使用链表存储等待同一把锁的线程，将线程添加到链表尾部，释放锁后

*  公平锁：将锁分配给链表头部的线程
 *  非公平锁：将锁分配个链表中的任意一个线程

将获得锁的线程从链表中移出

##### synchronized、ReentrantLock的比较 #####

*  synchronized是关键字，ReentrantLock是类
 *  机制不同，synchronized是操作对象的Mark Word，ReentrantLock是使用Unsafe类的park()方法加锁
 *  synchronized是非公平锁，ReentrantLock可以设置是否是公平锁
 *  ReentrantLock可以实现比synchronized更细粒度的控制，比如设置锁的公平性
 *  锁竞争不激烈时，synchronized的性能往往要比ReentrantLock高；锁竞争激烈时，synchronized膨胀为重量级锁，性能不如ReentrantLock
 *  ReentrantLock可以设置获取锁的等待时间，避免死锁

##### ReadWriteLock 读写锁 #####

ReadWriteLock将锁细粒度化分为读锁、写锁，synchronized、ReentrantLock 同一时刻最多只能有1个线程获取到锁，读锁同一时刻可以有多个线程获取锁，但都只能进行读操作，写锁同一时刻最多只能有1个线程获取锁进行写操作，其它线程不能进行读写操作。

读写锁做了更加细致的权限划分，加读锁时多个线程可以同时对共享资源进行读操作，相比于synchronized、ReentrantLock，在以读为主的情况下可以提高性能。

ReadWriteLock是接口，常用的实现类是ReentrantReadWriteLock 可重入读写锁。

public class Xxx { 
        public static ReentrantReadWriteLock lock = new ReentrantReadWriteLock(); 
        public static ReentrantReadWriteLock.ReadLock readLock = lock.readLock();  //从读写锁获取读锁
        public static ReentrantReadWriteLock.WriteLock writeLock = lock.writeLock();  //从读写锁获取写锁
        //.....
    
        public void a(){ 
            //....
    
            readLock.lock();
            //..... 操作共享资源
            readLock.unlock();
            
            //....
        }
    
    }

读锁、写锁的操作方式和ReentrantLock完全相同，都可以设置超时，这3种锁都是可重入锁

##### 锁降级 #####

在获取写锁后，写锁可以降级为读锁

public class Xxx { 
        public static ReentrantReadWriteLock lock = new ReentrantReadWriteLock(); 
        public static ReentrantReadWriteLock.ReadLock readLock = lock.readLock();  //读锁
        public static ReentrantReadWriteLock.WriteLock writeLock = lock.writeLock();  //写锁
        //.....
    
        public void a(){ 
            //....
    
            writeLock.lock();  //获取写锁
            //..... 对共享资源进行写操作
            readLock.lock();  //获取读锁（仍然持有写锁）
            writeLock.unlock();  //释放写锁（只持有读锁，写锁->读锁，锁降级）
            //..... //对共享资源进行读操作
            readLock.unlock();  //释放读锁
            
            //....
        }
    
    }

*  锁降级后，线程仍然持有写锁，需要自己释放写锁
 *  锁降级的意义在于：后续对共享资源只进行读操作，及时释放写锁可以让其它线程也能获取到读锁、进行读操作
 *  锁降级的应用场景：对数据比较敏感，在修改数据之后，需要校验数据
 *  写锁可以降级为读锁，但读锁不能升级为写锁

##### AQS如何用int值表示读写状态 #####

AbstractQueuedSynchronizer，抽象类

int，4字节32位，高位（前16位）表示读锁状态，低位（后16位）表示写锁状态。状态指的是重入次数，最大为2^16-1=65536

#### StampedLock ####

StampedLock是jdk1.8新增的类，可以获取读写锁、读锁、写锁，可以选择悲观锁、乐观锁，但StampedLock是不可重入的，且API比其他方式复杂，使用难度稍高。

#### ThreadLocal ####

ThreadLocal使用ThreadLocalMap存储所在线程中的线程私有数据，一个线程对应一个ThreadLocalMap。ThreadLocal可以实现各个线程私有数据的隔离，并发场景下可以实现无状态调用，常用于存储可能会被多个线程访问、但线程之间需要独立操作的变量。

//如果不指定初始值，默认为null（泛型不能为基本类型）
    private ThreadLocal<Integer> threadLocal1 = new ThreadLocal<>();
    //可以指定初始值
    private ThreadLocal<String> threadLocal2 = ThreadLocal.withInitial(() -> "aaa");
    private ThreadLocal<User> threadLocal3 = ThreadLocal.withInitial(() -> new User());
    
    public void test() { 
        //设置|更新值
        threadLocal1.set(100);
        threadLocal2.set("bbb");
        threadLocal3.set(new User("chy"));
    
        //获取值
        Integer integer = threadLocal1.get();
        String string = threadLocal2.get();
        User user = threadLocal3.get();
    
        //重置为初始值
        threadLocal1.remove();
        threadLocal2.remove();
        threadLocal3.remove();
    }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70_pic_center]

*  每个线程自己维护一个ThreadLocalMap，用于存储线程自身所有的ThreadLocal变量。
 *  map自然是以键值对的形式存储，键值对对应的内部类是Entry(ThreadLocal<?> k, Object v)，key是ThreadLocal对象，value是该ThreadLocal对象对应的值。

使用ThreadLocal的注意点

*  每个线程的ThreadLocal都是线程私有的，主线程的ThreadLocal也是主线程自身私有的，不会共享给子线程。

public void test() { 
    	ThreadLocal<Integer> threadLocal = new ThreadLocal<>();
    
        //此处操作的是主线程自己的ThreadLocal
        threadLocal.set(100);
        threadLocal.get();
    
        //lambda表达式可以访问外部变量，可以使用主线程中定义的threadLocal
        //但创建线程时,是把最初的ThreadLocal深拷贝一份，放在线程自身的ThreadLocalMap中，拷贝的是初值，不是主线程自身的ThreadLocal
        new Thread(() -> { 
            //此处取到的是初始值null
            threadLocal.get();
            threadLocal.set(200);
        }).start();
    
        new Thread(() -> { 
            //取到的也是初始值null
            threadLocal.get();
        }).start();
        
    }

*  线程池会复用线程，在提交给线程池的任务中使用ThreadLocal时，最后一定要使用remove()清除对ThreadLocal做的修改、重置到初始值，防止影响到此线程后续执行的使用了该ThreadLocal的任务。

ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
            6,
            20,
            10, TimeUnit.MINUTES,
            new LinkedBlockingQueue<Runnable>(100),
            new ThreadPoolExecutor.AbortPolicy()
    );
    
    ThreadLocal<Integer> threadLocal = new ThreadLocal<>();
    
    threadPoolExecutor.execute(() -> { 
        threadLocal.set(100);
        //...
        threadLocal.remove();
    });
    
    threadPoolExecutor.execute(() -> { 
        threadLocal.set(200);
        //...
        threadLocal.remove();
    });

#### volatile ####

public static volatile boolean flag = true;

*  volatile只能修饰变量
 *  2个作用：实现了所修饰变量的可见性、禁止指令重排序。可见性指的是变量值被某个线程修改时，其它使用此变量的线程可以观测到这个变化。
 *  volatile只实现了可见性，没有实现原子性，严格来说并没有实现线程安全。

volatile、synchronized的比较  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 3]

#### 原子类 ####

i++、++i、i–、--i、+=、-=等操作都不是原子性的，juc的atomic包下的类提供了自增、自减、比较赋值、取值修改等原子性方法，可以线程安全地进行操作，因为类中的方法都是原子性的，所有叫做原子类。

public class Xxx { 
    
        public static AtomicInteger i = new AtomicInteger(0);  //int
        public static AtomicLong l = new AtomicLong(0);  //long
        public static AtomicBoolean b = new AtomicBoolean(false);  //boolean
        public static AtomicReference<User> user = new AtomicReference<>(new User());  //引用
    
        public static AtomicIntegerArray intArr = new AtomicIntegerArray(new int[]{ 1, 23});  //int[ ]
        public static AtomicLongArray longArr = new AtomicLongArray(new long[]{ 1, 23});  //long[ ]
    
        public static AtomicIntegerFieldUpdater<User> userId1 = AtomicIntegerFieldUpdater.newUpdater(User.class,"id");  //对象的int型字段
        public static AtomicLongFieldUpdater<User> userId2 = AtomicLongFieldUpdater.newUpdater(User.class,"id");  //对象的long型字段
        public static AtomicReferenceFieldUpdater<User, List>  userOrderList= AtomicReferenceFieldUpdater.newUpdater(User.class, List.class,"orderList");  //对象的引用型字段
        
    }

*  原子类适合多线程读写简单数据类型的变量。只能保证单个变量的原子性，只能进行简单操作，如果要保证多个变量、稍微复杂点的操作的原子性，要用其它方式来实现线程安全（一般是加锁）。
 *  原子类使用CAS实现乐观锁，并发支持好、效率高
 *  CAS提交修改失败时会while循环进行重试，如果重试时间过长，会给cpu带来很大开销
 *  可能发生ABA问题。有2个原子类解决了ABA问题 ：AtomicMarkableReference、AtomicStampedReference，使用标记、邮戳实现乐观锁，和版本号、时间戳机制差不多，避免了ABA问题。

我们自己实现原子性操作时，也可以使用CAS算法。

#### 并发容器 ####

ArrayList、LinkedList、HashSet、HashMap等常见的普通集合容器都不是线程安全的，多线程并发读写同一个普通集合时（多个线程同时修改同一个集合，或者有的线程读、有的线程写），会抛出并发修改异常。

多线程并发读写集合时，不能使用普通集合，需要使用线程安全的集合

*  Vector、Hashtable 的方法都使用synchronized修饰，是线程安全的，但缺点较多，基本不使用这2个类。
 *  Collections.synchronizedXxx()可以将集合转换为线程安全的集合，是使用synchronized锁住整个集合，读写都加锁，同一时刻只能单线程操作该集合，效率低下。
 *  juc提供了常用的并发容器，线程安全，性能也不错。

##### Copy-On-Write集合容器CopyOnWriteArrayList、CopyOnWriteArraySet #####

//有序，按照插入顺序排列，内部使用Object[]存储元素
    CopyOnWriteArrayList<String> list = new CopyOnWriteArrayList<>();  
    
    //无序，CopyOnWriteArraySet内部使用CopyOnWriteArrayList存储元素
    CopyOnWriteArraySet<String> set = new CopyOnWriteArraySet<>();

//写操作都要先获取锁|加锁
    public boolean add(E e) { 
        final ReentrantLock lock = this.lock;
        lock.lock();
        try { 
            Object[] elements = getArray();
            int len = elements.length;
            //从原数组复制得到新数组
            Object[] newElements = Arrays.copyOf(elements, len + 1);
            //往新数组中添加元素
            newElements[len] = e;
            //指向新数组
            setArray(newElements);
            return true;
        } finally { 
            lock.unlock();
        }
    }
    
    //读操作都不加锁
    public E get(int index) { 
        return get(getArray(), index);
    }

*  线程进行写操作时，需要先获取锁，避免多个线程同时进行写操作。获取到锁后，复制内置数组得到一个新数组，在新数组上进行修改，最后将引用指向新数组。
 *  某个线程进行写操作时，其它线程不能进行写操作，但依然可以进行读操作，可以读取旧数组中的内容。

Copy-On-Write总结

*  设计思想：读写分离，最终一致性
 *  优点：多线程并发读的时候不加锁，性能好
 *  缺点：写的时候需要复制内置数组，元素多的时候复制时间长，同时存在2个数组，内用占用大，容易触发GC；且写的时候其它线程可以对旧数组进行读操作，可能存在数据不一致的情况。
 *  应用场景：适合读多写少的场景，比如黑名单、白名单。
 *  使用建议：每次调用修改的方法时，都会复制数组，要操作多个元素时，尽量使用addAll()、removeAll()之类的方法，一次性修改，只复制数组一次，可以提升性能。

##### ConcurrentHashMap、ConcurrentLinkedQueue #####

ConcurrentHashMap<String, String> map = new ConcurrentHashMap<>();  //map
    
    ConcurrentLinkedQueue<String> queue1 = new ConcurrentLinkedQueue<>();  //基于链表的队列

##### 阻塞队列LinkedBlockingQueue、ArrayBlockingQueue #####

常用于在生产者/消费者的线程协作模式中。

LinkedBlockingQueue<String> queue2 = new LinkedBlockingQueue<>();  //基于链表的阻塞队列，如果参数指定了元素个数，则有界、不能扩容，如果未指定，则无界
    
    ArrayBlockingQueue<String> queue3 = new ArrayBlockingQueue<>(20);  //基于数组的阻塞队列，指定容量，不能扩容（有界）
    ArrayBlockingQueue<String> queue4 = new ArrayBlockingQueue<>(20,true);  //可以指定是否是公平锁，默认false

LinkedBlockingQueue<String> queue = new LinkedBlockingQueue<>();  //基于链表的阻塞队列
            
    //入队的3个方法
    queue.offer("");  //返会操作结果，boolean，如果队列满了放不下，返回false
    queue.add("");  //返会操作结果，boolean，如果队列满了放不下，会抛出异常
    try { 
        queue.put("");  //如果队列满了，会阻塞线程，直到队列元素变少、可以放进去
    } catch (InterruptedException e) { 
        e.printStackTrace();
    }
    
    
    //出队的3个方法
    queue.poll();  //如果队列是空的，返回null
    queue.remove();  //如果队列是空的，会抛出异常
    try { 
        queue.take();  //在队列为空的时候，会阻塞线程，直到有元素可弹出
    } catch (InterruptedException e) { 
        e.printStackTrace();
    }

### 并发工具类 ###

#### CountDownLatch ####

CountDownLatch是一个计数器，常用于等待某些线程执行完毕

CountDownLatch countDownLatch = new CountDownLatch(2);  //指定次数
    
    new Thread(()->{ 
        //.....
        countDownLatch.countDown();  //次数-1
    }).start();
    
    
    new Thread(()->{ 
        //......
        countDownLatch.countDown();
    }).start();
    
    
    try { 
        countDownLatch.await();  //阻塞当前线程，直到次数为0时才继续往下执行，即等待2个线程执行完毕
        //......
    } catch (InterruptedException e) { 
        e.printStackTrace();
    }

#### CyclicBarrier 栅栏 ####

CyclicBarrier cyclicBarrier = new CyclicBarrier(3);  //指定await的线程数
    
    new Thread(()->{ 
        //......
        try { 
            cyclicBarrier.await();  //第一个
            //.....
        } catch (InterruptedException e) { 
            e.printStackTrace();
        } catch (BrokenBarrierException e) { 
            e.printStackTrace();
        }
    }).start();
    
    
    new Thread(()->{ 
        //......
        try { 
            cyclicBarrier.await();  //第二个
            //.....
        } catch (InterruptedException e) { 
            e.printStackTrace();
        } catch (BrokenBarrierException e) { 
            e.printStackTrace();
        }
    }).start();
    
    
    //.....
    try { 
        cyclicBarrier.await();  //第三个
        //.....
    } catch (InterruptedException e) { 
        e.printStackTrace();
    } catch (BrokenBarrierException e) { 
        e.printStackTrace();
    }

线程执行到await()处会阻塞，停下来，直到指定数量的线程都执行到await()才会继续往下执行。

CountDownLatch用于一些线程等待另一些线程执行完毕，类似超市收银员等待顾客挑好东西来结账；CyclicBarrier用于指定数量的线程互相等待，类似于大家指定地点集合。

#### Semaphore 信号量 ####

Semaphore用于限流

Semaphore semaphore = new Semaphore(2);  //指定信号量
    // Semaphore semaphore = new Semaphore(2,true); //可指定是否使用公平锁，默认false
    
    new Thread(() -> { 
        //......
        try { 
            semaphore.acquire();  //使用1个信号量，信号量-1。如果信号量为0，没有可用的信号量，阻塞线程直到获取到信号量
            //....
        } catch (InterruptedException e) { 
            e.printStackTrace();
        } finally { 
            semaphore.release();  //操作完释放信号量，信号量+1
        }
    }).start();

#### Exchanger ####

交换机，用于2条线程之间交换数据，只能用于2条线程之间，即一个Exchanger对象只能被2条线程使用（成对）

Exchanger<String> stringExchanger = new Exchanger<>();  //泛型指定交换的数据类型
    
    new Thread(()->{ 
        try { 
            String data = stringExchanger.exchange("are you ok？");
            System.out.println("线程1接收到的数据：" + data);  //ok
        } catch (InterruptedException e) { 
            e.printStackTrace();
        }
    }).start();
    
    new Thread(()->{ 
        try { 
            String data = stringExchanger.exchange("ok");
            System.out.println("线程2接收到的数据：" + data);  //are you ok
        } catch (InterruptedException e) { 
            e.printStackTrace();
        }
    }).start();

### 单例与线程安全 ###

单例有2种模式

*  饿汉式：在类加载时就实例化，线程安全
 *  懒汉式：在需要使用实例时才实例化，可能是线程不安全的

**饿汉式**

//饿汉式
    public class A { 
        private static A a=new A();  //用静态成员保存实例，调用构造方法创建实例。类加载时会初始化静态成员
        //..... 
    
        private A(){   //构造方法私有化，隐藏掉
    
        }
    
        public static A getInstance(){   //把获取实例的方法暴露出去
            return a;  //只有1步，原子性，线程安全
        }
    
        //..... 
    }

**懒汉式**

//懒汉式 写法一
    class A { 
        private static A a;  //用静态成员保存实例
        //..... 
    
        private A(){   //构造方法私有化，隐藏掉
    
        }
    
        public static A getInstance(){   //暴露获取实例的方法，多步，不具有原子性，不是线程安全的
            if (null==a){   
                a = new A();  
            }
            return a;
        }
    
        //..... 
    
    }

写法二：用synchronized修饰获取获取实例的静态方法，但这种方式获取实例时会锁住类，使多个线程不能同时获取实例，效率低下

//懒汉式 写法三
    class A { 
        private static volatile A a;  //volatile禁止指令重排序
        //..... 
    
        private A(){ 
    
        }
    
        public static A getInstance(){ 
            if (null==a){ 
                synchronized (A.class){   //优化写法，只在创建实例时锁住类
                    a = new A();
                }
            }
            return a;
        }
    
        //..... 
    
    }

### 锁的分类 ###

*  自旋锁：未获取到锁时进入等待状态，多线程切换上下文会消耗系统资源，频繁切换上下文不值得，jvm会在线程没获取到锁时，暂时执行空循环等待获取锁，即自旋，循环次数即自旋次数；如果在指定自旋次数内没获取到锁，则挂起线程，切换上下文，执行其它线程。锁默认是自旋的。
 *  自适应自旋锁：自旋次数不固定，由上一次获取该锁的自旋时间及锁持有者的状态决定，更加智能  
     
 *  阻塞锁：阻塞锁会改变线程的运行状态，让线程进入阻塞状态进行等待，当获得相应信号（唤醒或阻塞时间结束）时，进入就绪状态  
     
 *  重入锁：已持有锁的线程，在未释放锁时，可以再次获取到该锁

public class Xxx{ 
        public final static ReentrantLock lock=new ReentrantLock();
    
        public void a() { 
            lock.lock();
            //.....
            b();  //如果锁是可重入的，则b()直接获取到锁；如果锁不是可重入的，则b()需要单独获取获取锁，但锁还没被a()释放，b()会一直获取不到锁
            //.....
            lock.unlock();
        }
    
        public void b() { 
            lock.lock();
            //......
            lock.unlock();
        }
    
    }

*  读锁：是一种共享锁 | S锁（share），多条线程可同时操作共享资源，但都只能进行读操作、不能进行写操作
 *  写锁：是一种排它锁 | 互斥锁 | 独占锁 | X锁，同一时刻最多只能有1个线程可以对共享资源进行写操作，其它线程不能对该资源进行读写  
     
 *  悲观锁：每次操作共享资源时，认为期间其它线程一定会修改共享资源，每次操作共享数据之前，都要给共享资源加锁
 *  乐观锁：每次操作共享资源时，认为期间其它线程一般不会修改共享资源，操作共享资源时不给共享资源加锁，只在提交修改时验证数据是否被其它线程修改过，常用版本号等方式实现乐观锁  
     
 *  公平锁：等待锁的线程按照先来先得顺序获取锁（慎用）
 *  非公平锁：释放锁后，等待锁的线程都可能获取到锁，不是先来先得

非公平锁可能导致某些线程长时间甚至一直获取不到锁，但这种情况毕竟是极少数；使用公平锁，为保证公平性有额外的开销，会降低性能，所以一般使用非公平锁

*  偏向锁：初次获取锁后，锁进入偏向模式，当获取过锁的线程再次获取该锁时会简化获取锁的流程，即锁偏向于曾经获取过它的线程

锁消除：编译时会扫描上下文，自动去除不可能存在线程竞争的锁

锁细化：如果只操作共享资源的一部分，不用给整个共享资源加锁，只需给要操作的部分加锁即可。使用细粒度的锁可以让多个线程同时操作共享资源的不同部分，提高效率。

锁粗化：要操作共享资源的多个部分，如果每次只给部分加锁，频繁加锁、释放锁会影响性能，可以扩大锁的作用范围，给整个共享资源加锁，避免频繁加锁带来的开销。

### 指令重排序 ###

指令重排序：编译器、处理器会对指令序列重新排序，提高执行效率、优化程序性能

int a=1;
    int b=1;

以上2条指令会被重排序，可能2条指令并发执行，可能int a=1;先执行，可能int b=1;先执行。

**指令重排序遵循的2个原则**

1、 数据依赖性，不改变存在数据依赖关系的两个操作的执行顺序。

int a=1;
    int b=a;

b依赖于a，重排序不能改变这2个语句的执行顺序

2、as-if-serial原则，重排序不能改变单条线程的执行结果

int a=1;
    int b=a;

执行结果是a=1、b=1，重排序后执行得到的也要是这个结果

### 数据同步接口 ###

**中间表的设计**

*  只存储要使用的字段即可
 *  需要用一个字段记录该条数据的状态：已入库、正在处理、处理时发生异常、已处理
 *  需要用一个字段记录数据入库时间
 *  需要用一个字段记录处理时间

记录时间是为了日后好排查问题、统计分析

**对中间表的处理**

可以使用生产者/消费者的线程协作模式

*  生产者分批读取中间表中未处理的数据 where status=‘xxx’，放到仓库中。因为数据量一般很大，所以通常要分批读取，防止仓库装不下。如果要操作多张表，很多操作都差不多，可以抽象出接口
 *  消费者处理仓库中的数据

操作时需要更新中间表中的数据状态、处理时间

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200608002234299.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200608003612857.PNG?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200608002615468.PNG?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20210616191759817.PNG?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200608113420369.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ==,size_16,color_FFFFFF,t_70