2026/08/05
Synchronized的实现原理
Synchronized底层是基于JVM的监视器锁,在被Synchronized修饰的代码块中,在字节码层面会在代码块前加入monitorenter指令,在代码块后面会加上monitorexit指令,被修饰的代码块同时只能允许一个线程进入执行,其他未获取到锁的线程会在外部阻塞等待
在Java8之后,Synchronized锁进行了优化,并不是一进来就是重量级锁,而是有一个所升级的过程,首先当没有线程进入时,是一个无锁的状态,有一个线程进入时,就会升级成偏向锁,当有另一个线程与之竞争时,就会升级成轻量级锁,此时这个未获取到锁的线程并不会直接阻塞,而是通过自旋挂起,等待另一个线程释放锁。如果等待锁的线程自旋时间过长或者此时有多个线程同时竞争锁,此时synchronized就会升级成重量级锁,所有未获取到锁的线程都会进入entryList阻塞等待。主动放弃锁的线程进入waitSet队列
Synchronized和ReentrantLock
Synchronized和ReentrantLock都是互斥锁,不同的是Synchronized是基于JVM层面的监视器锁实现的,而ReentrantLock是基于CAS和AQS实现的。
Synchronized锁适用于一些简单的场景,因为Synchronized加锁和释放锁都比较简单,只要进入代码块就会自动加锁,退出代码块就会自动释放锁。而ReentrantLock需要手动加锁和释放锁,通常会配合try-finally块保证代码执行完毕后一定会释放锁
除此之外,ReentrantLock还可以实现可中断,等待锁的线程可以被中断,而不是像等待Synchronized锁的线程那样,一直被阻塞。并且ReentrantLock可以实现尝试获取锁,在一定时间内如果没有获取到锁,就直接取消,不再获取锁。
ReentrantLock还可以实现公平锁机制,保证每个线程排队获取锁,而不是通过竞争来获取锁,防止了线程饥饿
ReentrantLock可以创建多个Condition对象,实现精准唤醒,而synchronized只能关联一个Object的wait/notify,无法精确唤醒
基于AQS实现的Java类
基于AQS实现的Java类分两大类:锁和同步器
锁,即实现了JUC包下的Lock接口的类,例如ReentrantLock,
ReadWriteLock:读写锁,读锁是共享锁,写锁是排他锁,读锁可以多线程同时进入读数据,而写锁只能一个线程进入修改数据。适用于读多写少的场景
同步器类,通常不实现Lock接口
Semaphore,共享变量,通过一个计数器来控制访问资源的线程,所有需要访问资源的线程都需要通过tryAcquire获取一个许可,然后计数器减一,只有获取到许可的线程才能访问资源,当释放资源时,通过release方法释放资源,计数器加一
CountDownLatch,允许一个或多个线程等待其他线程执行完毕。当有线程执行代码完毕,计数器减1,知道计时器的值为0时,等待的线程就会被唤醒。AQS的state被拆分为高16位(读锁计数)和低16位(写锁计数)
CyclicBarrier,底层是基于ReentrantLock和Condition实现的。允许一组线程互相等待,同样是通过计数器来判断,每当有一个线程执行到屏障时,计数器就会减一,直到所有线程都执行到屏障处,然后在继续执行后续的方法
线程池的参数
- corePoolSize:核心线程数,是线程池执行任务的主力军
- maxPoolSize:最大线程数,等于核心线程数加辅助线程数
- blockingQueue:阻塞队列,当核心线程数满时,还有任务进入,任务就会先进入到阻塞队列中
- keepAliveTime:线程的存活时间,当超过这个时间,辅助线程没有执行任务,辅助线程就会被销毁
- timeUnit:时间单位
- ThreadFactory:线程工厂,通常可以用于定义这组线程池的名字
- RejectedExecutionHandler:拒绝策略,当阻塞队列满了,并且辅助线程也全都在执行任务,此时如果还有任务进入,就会执行拒绝策略。拒绝策略通常有以下几类,直接抛弃,不执行任务;交给提交任务的线程处理;抛出异常;不进行任何处理;自定义拒绝策略
当核心线程都在执行任务时,再进来的任务会先进入阻塞队列,如果阻塞队列也满了,还有任务进来,就会开始创建辅助线程来执行任务
线程/进程之间该如何通信
线程之间的通信通常是依靠共享变量来实现,或者wait,notify等方法。JUC中通常还可以利用LockSupport的park和unpark来实现
进程之间的通信通常需要通过一个管道pipeline来实现,也可以利用消息队列或者通过http请求等实现
