sychornized底层实现原理？

java SE 1.6对synchronized进行了各种优化，使得它在有些情况下没有那么重（陈本很高）。

作用范围有三个：普通方法、静态方法、同步代码块

• 普通方法：锁的是当前实例对象
• 静态方法：锁的是类对象
• 代码块：锁的是括号中的对象

那么是怎么锁上的呢？

通过javac -p 类，获得反编译我们看到，其实就是对一个monitor对象的争夺。

但是代码块和方法有点区别

代码块：当进入方法的时候，执行monitorenter，获得monitor对象的所有权，这个时候monitor对象计数为1，此时当前线程就获得了monitor对象，也就是获得了这把锁；再次进入，如果你已经是这个锁的拥有者，计数+1；当执行完monitorexit以后，相应的计数-1，直到计数0，释放当前锁。

方法：同理，不过同步方法是隐士调用的monitorenter和monitorexit。归根到底就是对monitor对象的争夺。

那么这个monitor对象中有什么特殊的呢？

其实没有什么特殊的，从代码书写你就可以看出来，每个对象都可以作为一把锁，那么synchronized锁的是什么呢？其实sychronized使用的锁就存在java对象头中。

java对象头

什么叫对象头：java对象在内存中分为对象头、实例数据、对其填充三部分。对象头又包括MarkWord、ClassPoint。

对象头有多大呢？

32为虚拟机中，如果对象是数组类型，使用12个字节存储；如果不是数组类型，使用8个字节存储。

MarkWord中存储的是什么呢？

默认存储的是对象的hashcode、分代年龄、锁标志位。

锁升级的过程

1.6为了减少锁获得和释放带来的性能消耗，引入偏向锁、轻量级锁

锁一共有四种状态无锁状态、偏向锁、轻量级锁、重量级锁

锁可以升级，但是不能降级；无锁->偏向锁->轻量级锁->重量级锁

偏向锁

因为研究人员发现，大多数情况下，锁都是有同一线程多次获得，为了让线程获得锁的代价更低，引入偏向锁。

锁升级的过程

首次，线程访问同步代码块，并且获得锁的情况下，会在对象头和栈帧中的锁记录中记录线程ID

再次，检查一下对象头中的线程ID是不是自己；是，直接获得偏向锁，执行同步代码块；不是，查看对象头锁标志位，检查获取当前锁的线程是不是偏向锁；如果没有设置锁标志位，使用CAS竞争锁，如果设置了，使用CAS将对象头偏向锁线程ID设置成自己的。如果设置成功了，当前线程获取偏向锁，执行代码。如果竞争失败了，执行偏向锁的撤销

偏向锁的撤销，需要等到全局安全点（就是这个点没有正在执行的字节码），首先、暂停拥有偏向锁的线程，检查偏向锁是否活动，不活动，对象头设置无锁；存活，拥有偏向锁的栈执行，栈中的记录和对象头要么偏向其他线程，要么无锁，或者标记该对象不适合做偏向锁，升级为轻量级锁。

轻量级锁枷锁

线程执行同步块之前，JVM在当前线程的栈帧记录中创建存储锁记录的空间，将Markword复制过来；然后使用CAS替换对象头中的线程ID，成功，获得锁，失败，根据当前线程栈帧中的锁记录自旋。

轻量级锁解锁

使用原子级操作，将当前线程中的锁记录替换回对象头中，成功，表示没有发生竞争，失败了，存在竞争，当前锁膨胀成重量级锁。释放锁会唤醒其他等待的线程。

究竟该使用sychronized还是Lock呢？

一个是JDK层面的sychronized，一个是JVM层面的Lock。具体该使用哪个应该结合具体的场景来使用，脱离具体业务都是扯淡。比如你高峰期时使用sychronized，那么过了高峰期，都是重量级锁，是不是也不合适。

线程的状态的切换

• 创建一个线程线程处于New状态
• 调用start方法以后进入就绪状态
• 线程获取时间片以后进入到运行状态
• 获取同步失败会进入阻塞状态
• 获取到锁以后会从阻塞状态->就绪状态，在获取时间片以后变成运行状态
• 线程运行结束会进入Terminated状态

CAS和ABA问题

CAS是一种解决线程同步问题的方式，

• 是一种乐观锁，只有在回写操作的时候才会加锁，认为并发问题一般不会发生，写操作的时候判断变量的值是不是=预期值，如果不等于说明被改变，重新读取，如果没有改变就写回
• 比较并写回的操作属于原子操作，由操作系统保证线程的安全性，保证线程不会中断

ABA：当前线程读取变量值A，其他线程改写B，然后在改写成A，对当前线程而言还是A，就会造成ABA问题，可能对结果没有影响，但是也需要防范。你老婆出轨以后还是你老婆吗？

sleep和yield的区别？

• sleep不考虑线程的优先级，yield会让给比自己优先级高的线程
• sleep会使当前线程进入阻塞状态，让出CPU（wait也让出CPU），但是不会让出锁（意思就是如果你有sychronized关键字，虽然我会阻塞，但是其他线程也得不到运行机会），yield使当前线程重新回到可执行状态
• sleep方法会抛出InterruptedException异常，yield方法无任何异常
• sleep有更好的移植性

wait()

• 需要和notify()、notifyAll()方法一起使用
• 需要在同步代码块中使用，因为是用来协调共享对象的读取，Object类的方法
• 和sleep的区别是，wait会释放锁，会使得当前线程暂停执行，加入对象等待池
• notify并不能确切的唤醒哪个对象，由JVM确定
• notityAll：唤醒所有等待的线程，进入就绪状态，具备争夺资格

join

• 当前线程等待调用join的线程执行完毕在运行

volatile

特点：

• 禁止指令重排（JVM会在对结果没有影响的前提下对代码顺序调整）
• 保证不同线程对变量操作的内存可见性

使用了就能保证线程安全性吗？

• volatile只能保证该变量的原子性，但是如果线程是复合操作的话并不能保证线程安全性

• volatile 只能保证写后读的可见性，比如，A线程读取变量，进行+1写回的同时，线程B获取时间分片，线程A阻塞，线程B获取数值+1，写进去，因为回写操作只能保证其他线程在读取操作时，发现自己缓存无效，才会重新读主存的值。

volatile写操作会使其他线程读缓存失效，如果其他线程在写之前已经读取，要写入的时候，是无法失效的

volatile的本质是告诉JVM寄存器，这个变量是不确定的，你要使用 就需要从内存中读取，sychronized是锁定，其他线程不可见的

volatile底层实现机制

• 加了volatile关键字以后，汇编指令底层会在变量前加上Lock指令
• Lock指令会引发，将当前缓存行的数据写回主内存，同时使其他线程缓存了该内存的地址无效

volatile在项目中的使用

• 单例模式下的双重检查
• 多线程下的循环终止

线程池

Executor线程池

如果对线程池原理不是很清楚的情况下，Executors提供了一些常用的线程池

• newSingleThreadExecutor：单一线程池，如果出现异常会再创建一个线程，保证所有任务的执行都按照任务的提交顺序进行
• newFixedThreadPool：固定大小线程池，提交一个任务就创建一个线程，直到线程最大值
• newCachedThreadPool：可缓存线程池，会回收线程，当新任务提交又会新增线程，使用SynchronousQueue作为阻塞队列，
• newScheduledThreadPool：大小无限制，周期性执行任务

线程池参数的意义

• corePoolSize：核心线程最大值
• maximumPoolSize：线程池能拥有的最多线程数
• workQueue：缓存任务的阻塞队列

三者的关系

• 如果没有空闲的线程，并且当前运行线程小于核心线程，添加新的线程执行任务
• 如果没有空闲的线程，并且当前运行线程数目等于核心线程，并且任务队列没有满的情况下，任务加入队列，不添加新的线程
• 如果没有空闲的线程，并且当前运行线程数目小于最大线程数，任务队列已经满的情况下，添加新的线程执行任务
• 如果没有空闲的线程，并且当前运行线程输入等于最大线程数，根据hanlder定制的策略执行拒绝新的任务的提交

拒绝策略

• 直接抛出RejectedExecutionException异常
• 由像线程池提交任务的线程进行执行
• 抛弃最久的任务
• 抛弃当前任务

任务队列

• SynchronousQueue<Runnable>：队列中不保存任务，线程池不空闲的话，提交任务就受阻，只有有空闲，才能入禁区，无界队列
• LinkedBlockingQueue<Runnable>：以是有界的，也可以是无界的，但在Executors中默认使用无界的
• ArrayBlockingQueue<Runnable>：数组组成的有界阻塞队列，FIFO
• DelayQueue：优先级队列无阻塞队列

如何知道线程池是否结束

• shutDown()：拒绝新任务的提交，等待线程执行完毕在退出线程池
• shutDownNow()：拒绝新任务的提交，立马退出线

调用isShotDown()只是返回你是否调用过shutDown方法，应该调用isTerminated()方法进行判断

通常有以下几种方式

• 死循环中调用isTerminated()方法，判断线程是否都执行完毕
• 使用闭锁countDownLatch(),线程执行完毕调用countDown()，调用shutDown方法后调用await方法，会等到线程执行完毕
• 调用线程池的awaitTermination方法。

execute()和submit()的区别？

• execute在Excutor接口中，submit在ExcutorService中
• submit可以返回Future对象，execute没有

java中的锁

sychronized和lock的比较

• sychronized：隐士的获取锁，但是固化了锁的获取和释放；Lock接口扩展性更好，种类更丰富，支持重入
• Lock使用简单，可以非阻塞的获取锁，同时能响应中断、释放锁，同时可以超时获取锁，超过时间就返回

不要在try中使用lock，应该写在外面，因为如果获取锁发生异常会立刻释放锁，导致程序出现异常

队列同步器

工作原理：内部通过维护一个int变量表示同步状态，通过内置的FIFO队列完成资源获取线程的排队工作

使用方法：使用静态内部类，继承AbstarctQueuedSynchronizer，实现抽象方法

独占式获取锁与释放锁：调用tryaccqurie，线程安全的获取同步状态，如果获取失败，将当前线程构建节点，使用CAS操作的方式加入到队尾，并且通过死循环的方式获取线程的同步状态

释放锁：release方法在释放了同步状态以后，会唤醒后继节点

重入锁

ReentrantLock：支持重入，同时也支持公平、非公平（默认）

公平锁和非公平锁的区别？

• 公平锁追求绝对的FIFO，非公平锁CAS成功就获取锁，效率更高
• 公平锁需要大量的上下文切换，代价高昂；非公平所可能造成线程'饥饿'，但是减少线程切换，保证了吞吐量
• 公平锁就是在尝试枷锁的时候判断一下前面节点

读写锁

分离读锁、写锁提高性能。写锁同一时刻所有线程都被阻塞。读锁同一时刻可以允许多个读线程访问。

出现背景

ReentrantLock虽然保证了线程安全性能，但是也浪费了一定资源，因为多个读操作是不会发生线程安全的问题的，读写锁保证多个线程读操作，同时又很好的保证了写线程的安全性

底层原理

通过高低16进行区分是读锁还是写锁，高16位：读锁，低16位：写锁

获取写锁的时候，如果读锁被获取，写锁是获取不到的，因为要保证写锁的操作对读锁可见

使用场景

更新缓存情况

class CachedData {
   Object data;
   volatile boolean cacheValid;
   final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

   void processCachedData() {
       //获取读锁
     rwl.readLock().lock();
     if (!cacheValid) {
       // Must release read lock before acquiring write lock
       //读锁释放
       rwl.readLock().unlock();
       //获取写锁
       rwl.writeLock().lock();
       try {
         // Recheck state because another thread might have
         // acquired write lock and changed state before we did.
         if (!cacheValid) {
           data = ...
           cacheValid = true;
         }
         // Downgrade by acquiring read lock before releasing write lock
         //锁降级，如果其他线程获取写锁，当前线程无感知，因此要先获取读锁，等待当前线程做完业务
         rwl.readLock().lock();
       } finally {
         //最后释放写锁
         rwl.writeLock().unlock(); // Unlock write, still hold read
       }
     }

     try {
       use(data);
     } finally {
       //使用完毕释放读锁，因为可能不走缓存，但是加上锁了
       rwl.readLock().unlock();
     }
   }
 }

锁降级

获取写锁->获取读锁->释放写锁->释放读锁

不支持锁升级

适用于读多写少的场景

LockSupport

出现背景

LockSupport提供几个带有park的方法，实现线程的通信

底层原理

调用的底层UNSAFE的park和unpark方法

使用场景

交替打印字符
    循环列表1
    输出当前字符
    unpark线程2
    park当前线程
    
    循环列表2
    输出当前字符
    unpark线程1
    park当前线程

Condition

用来替代wait，notify/notifyall的线程通知类，通过和Lock接口配合，可以使得等待通知更加灵活

使用场景

生产者消费者问题

生产能力>消费能力：生产者调用condition.await()方法，让出当前线程，等待消费能力上来，调用conditon.signal()方法，唤醒生产者

反之亦然

底层实现

等待队列、等待、通知

等待队列：Condition拥有首尾节点的引用，调用await方法以后，会将当前线程构造成节点，连接到队列，更新尾节点引用

唤醒队列：

Fork/Join

Fork：将大任务进行切分成若干个子任务进行并行执行

Join：合并这些子任务结果，得到大任务的结果

框架设计

• 1、分割任务。不停细化任务，分割出来足够小的子任务
• 2、任务结果合并。子任务放在双端队列中，启动线程从双端队列拿任务，执行结果放在一个对立，启动线程合并执行结果，这就是工作窃取算法

并发工具类

CountDownLatch

允许一个或多个线程等待其他线程完成操作。

• 初始化构建CountDownLatch对象的线程数
• 线程执行完毕调用countDown方法
• 主线程调用await方法等待

同步屏障CyclicBarrier

构建一个同步点，阻塞到达线程，直接满足条件释放。相当于countDownLatch的反操作

• 初始化构建CyclicBarrier对象
• 线程调用await方法，知道满足条件

使用场景

Excel中记录薪酬，可以使用CyclicBarrier，利用多线程计算每个场景，然后主线程合并计算结果

控制并发线程数的Semaphore

比如，红绿灯控制可以通行100辆车，那么第101就是红灯，但是如果前5量走了，后面是可以同行的，其实就是一个并发数的控制

可以用在数据库连接中。

• 构造Semaphore方法，传入并发数
• 调用accquire方法在多线程中尝试控制并发

线程分析实战

https://blog.csdn.net/luqiang81191293/article/details/106484628/

什么情况应该进行性能分析？

• 性能调优，就是充分利用机器，使其性能最大化
• 如果在单机CPU，不论多大压力CPU都没有办法达到100%，说明程序需要优化（这里的优化指的是你的代码没有好好利用CPU，不是说你的程序压力不大）

几种常见的性能瓶颈

• 锁的使用不当，不相关的方法使用了同一把锁，对象锁和类锁（一不小心锁定了所有对象）
• 锁粒度太大，不需要锁的后续代码也加上锁
  • 如果你锁住的是CPU密集计算，缩小同步代码块也不能带来性能上提升，但是也不会下降
  • 如果你锁住的是IO密集型计算，这时候CPU是空闲的，如果此时让CPU运行起来会带来性能提升
  • 总之，缩小锁住的代码块的力度总会提升性能的
• sleep的滥用
• 不恰当的线程模型
• 内存泄漏，导致频发GC（内存泄漏：程序申请到内存无法释放，导致其他程序无法使用你用过的内存，内存溢出最终导致内存溢出）

线程堆栈善于分析的如下问题

• 系统无缘无故CPU过高
• 系统挂起，无响应
• 系统运行越来越慢
• 线程死锁、死循环、饿死等
• 线程数量太多导致系统失败