泊头市做网站价格,wordpress api key,工程公司资质怎么申请,做产地证新网站Synchronized同步锁优化方法
1.6之前比较重量级#xff0c;1.6后经过优化性能大大提升 使用Synchronized实现同步锁住要是两种方式#xff1a;方法、代码块。
1.代码块 Synchronized在修饰同步代码块时#xff0c;是由 monitorenter和monitorexit指令来实现同步的。进入mo…Synchronized同步锁优化方法
1.6之前比较重量级1.6后经过优化性能大大提升 使用Synchronized实现同步锁住要是两种方式方法、代码块。
1.代码块 Synchronized在修饰同步代码块时是由 monitorenter和monitorexit指令来实现同步的。进入monitorenter 指令后线程将持有Monitor对象退出monitorenter指令后线程将释放该Monitor对象。
2.方法 当Synchronized修饰同步方法时并没有发现monitorenter和monitorexit指令而是出现了一个ACC_SYNCHRONIZED标志。这是因为JVM使用了ACC_SYNCHRONIZED访问标志来区分一个方法是否是同步方法。当方法调用时调用指令将会检查该方法是否被设置ACC_SYNCHRONIZED访问标志。如果设置了该标志执行线程将先持有Monitor对象然后再执行方法。在该方法运行期间其它线程将无法获取到该Mointor对象当方法执行完成后再释放该Monitor对象。
JVM中的同步是基于进入和退出管程Monitor对象实现的。每个对象实例都会有一个MonitorMonitor可以和对象一起创建、销毁。Monitor是由ObjectMonitor实现而ObjectMonitor是由C的ObjectMonitor.hpp文件实现。
当多个线程同时访问一段同步代码时多个线程会先被存放在ContentionList和_EntryList 集合中处于block状态的线程都会被加入到该列表。接下来当线程获取到对象的Monitor时Monitor是依靠底层操作系统的Mutex Lock来实现互斥的线程申请Mutex成功则持有该Mutex其它线程将无法获取到该Mutex竞争失败的线程会再次进入ContentionList被挂起。
如果线程调用wait() 方法就会释放当前持有的Mutex并且该线程会进入WaitSet集合中等待下一次被唤醒。如果当前线程顺利执行完方法也将释放Mutex。
因为涉及到线程的阻塞和挂起等操作这也是Synchronized比较重量级的原因。下面看看jdk源码是怎么进行优化的。
JDK1.6引入了偏向锁、轻量级锁、重量级锁概念来减少锁竞争带来的上下文切换而正是新增的Java对象头实现了锁升级功能。当Java对象被Synchronized关键字修饰成为同步锁后围绕这个锁的一系列升级操作都将和Java对象头有关。对象头内容如下 锁升级过程如下
一句话概括总结通过一些方式去竞争锁在竞争中逐渐提高锁的级别代价也越来越大。一开始只需查询对象头然后是CAS竞争最后直接挂起阻塞线程。
锁的不同重量级对应着不同的场景我们需要根据实际的业务情况去具体优化。
1.偏向锁主要用来优化同一线程多次申请同一个锁的竞争。在某些情况下大部分时间是同一个线程竞争锁资源例如在创建一个线程并在线程中执行循环监听的场景下或单线程操作一个线程安全集合时同一线程每次都需要获取和释放锁每次操作都会发生用户态与内核态的切换。
因此在高并发场景下当大量线程同时竞争同一个锁资源时偏向锁就会被撤销发生stop the word后 开启偏向锁无疑会带来更大的性能开销这时我们可以通过添加JVM参数关闭偏向锁来调优系统性能示例代码如下
-XX:-UseBiasedLocking //关闭偏向锁默认打开
或
-XX:UseHeavyMonitors //设置重量级锁2.轻量级锁适用于线程交替执行同步块的场景绝大部分的锁在整个同步周期内都不存在长时间的竞争。
3.自旋锁和重量级锁在锁竞争不激烈且锁占用时间非常短的场景下自旋锁可以提高系统性能。一旦锁竞争激烈或锁占用的时间过长自旋锁将会导致大量的线程一直处于CAS重试状态占用CPU资源反而会增加系统性能开销。所以自旋锁和重量级锁的使用都要结合实际场景。
在高负载、高并发的场景下我们可以通过设置JVM参数来关闭自旋锁优化系统性能示例代码如下
-XX:-UseSpinning //参数关闭自旋锁优化(默认打开)
-XX:PreBlockSpin //参数修改默认的自旋次数。JDK1.7后去掉此参数由jvm控制4.动态编译优化JIT编译器对锁的粒度增大或减小。例如几个相邻的同步块使用的是同一个锁实例那么 JIT 编译器将会把这几个同步块合并为一个大的同步块从而避免一个线程“反复申请、释放同一个锁”所带来的性能开销。而粒度减小的典型案例就是JDK8之前的ConcurrentHashMap中用的Segment分段锁减小锁粒度实现增大并发量避免锁被升级为重量级锁。 Lock同步锁优化方法
和synchronized的对比 Lock是一个接口AQSAbstractQueuedSynchronizer是一个抽象类。Lock锁是基于Java实现的锁Lock是一个接口类常用的实现类有ReentrantLock、ReentrantReadWriteLockRRW它们都是依赖AbstractQueuedSynchronizerAQS类实现的。
AQS类结构中包含一个基于链表实现的等待队列CLH队列用于存储所有阻塞的线程AQS中还有一个state变量该变量对ReentrantLock来说表示加锁状态。
该队列的操作均通过CAS操作实现我们可以通过一张图来看下整个获取锁的流程。简而言之通过CAS竞争和队首节点去获得锁。 锁分离优化Lock同步锁默认的ReentrantLock是独占锁在大部分业务场景中读业务操作要远远大于写业务操作。而在多线程编程中读操作并不会修改共享资源的数据如果多个线程仅仅是读取共享资源那么这种情况下其实没有必要对资源进行加锁。如果使用互斥锁反倒会影响业务的并发性能那么在这种场景下有没有什么办法可以优化下锁的实现方式呢
1.读写锁ReentrantReadWriteLock
RRW也是继承AQS实现内部维护了两个锁读锁和写锁实现的关键是将AQS的同步变量state分为高16位和低16位分别表示读写。
2.读写锁再优化之StampedLock
RRW被很好地应用在了读大于写的并发场景中然而RRW在性能上还有可提升的空间。在读取很多、写入很少的情况下RRW会使写入线程遭遇饥饿Starvation问题也就是说写入线程会因迟迟无法竞争到锁而一直处于等待状态。
在JDK1.8中Java提供了StampedLock类解决了这个问题。StampedLock不是基于AQS实现的但实现的原理和AQS是一样的都是基于队列和锁状态实现的。与RRW不一样的是StampedLock控制锁有三种模式: 写、悲观读以及乐观读并且StampedLock在获取锁时会返回一个票据stamp获取的stamp除了在释放锁时需要校验在乐观读模式下stamp还会作为读取共享资源后的二次校验后面我会讲解stamp的工作原理。
我们先通过一个官方的例子来了解下StampedLock是如何使用的代码如下
public class Point {private double x, y;private final StampedLock s1 new StampedLock();void move(double deltaX, double deltaY) {//获取写锁long stamp s1.writeLock();try {x deltaX;y deltaY;} finally {//释放写锁s1.unlockWrite(stamp);}}double distanceFormOrigin() {//乐观读操作long stamp s1.tryOptimisticRead(); //拷贝变量double currentX x, currentY y;//判断读期间是否有写操作if (!s1.validate(stamp)) {//升级为悲观读stamp s1.readLock();try {currentX x;currentY y;} finally {s1.unlockRead(stamp);}}return Math.sqrt(currentX * currentX currentY * currentY);}
}我们可以发现一个写线程获取写锁的过程中首先是通过WriteLock获取一个票据stampWriteLock是一个独占锁同时只有一个线程可以获取该锁当一个线程获取该锁后其它请求的线程必须等待当没有线程持有读锁或者写锁的时候才可以获取到该锁。请求该锁成功后会返回一个stamp票据变量用来表示该锁的版本当释放该锁的时候需要unlockWrite并传递参数stamp。
接下来就是一个读线程获取锁的过程。首先线程会通过乐观锁tryOptimisticRead操作获取票据stamp 如果当前没有线程持有写锁则返回一个非0的stamp版本信息。线程获取该stamp后将会拷贝一份共享资源到方法栈在这之前具体的操作都是基于方法栈的拷贝数据。
之后方法还需要调用validate验证之前调用tryOptimisticRead返回的stamp在当前是否有其它线程持有了写锁如果是那么validate会返回0升级为悲观锁否则就可以使用该stamp版本的锁对数据进行操作。
相比于RRWStampedLock获取读锁只是使用与或操作进行检验不涉及CAS操作即使第一次乐观锁获取失败也会马上升级至悲观锁这样就可以避免一直进行CAS操作带来的CPU占用性能的问题因此StampedLock的效率更高。 乐观锁优化并行操作 优化多线程上下文切换 并发容器的选择 线程池的设置 协程的使用
