java锁优化

2020-01-28 16:01:21来源：博客园阅读 ()

java锁优化

一、锁优化的思路和方法

锁优化是指：在多线程的并发中当用到锁时，尽可能让性能有所提高。一般并发中用到锁，就是阻塞的并发，前面讲到一般并发级别分为阻塞的和非阻塞的（非阻塞的包含：无障碍的，无等待的，无锁的等等），一旦用到锁，就是阻塞的，也就是一般最糟糕的并发，因此锁优化就是在堵塞的情况下去提高性能；所以所锁的优化就是让性能尽可能提高，不管怎么提高，堵塞的也没有无锁的并发底。让锁定的障碍降到最低，锁优化并不是说就能解决锁堵塞造成的性能问题。这是做不到的。

方法如下：

? 减少锁持有时间

? 减小锁粒度

? 锁分离

? 锁粗化

? 锁消除

二、减少锁持有时间

举例：

public synchronized void syncMethod(){
  othercode1();
  mutextMethod();
  othercode2();
}

使用这个锁会造成其他线程进行等待，因此让锁的的持有时间减少和锁的范围，锁的零界点就会降低，其他线程就会很快获取锁，尽可能减少了冲突时间。

改进优化如下：

public void syncMethod2(){
  othercode1();
  synchronized(this){
    mutextMethod();
  }
  othercode2();
}

三、减小锁粒度

? 将大对象，拆成小对象，好处是：大大增加并行度，降低锁竞争（同时偏向锁，轻量级锁成功率提高）

? 提高偏向锁，轻量级锁成功率

? HashMap的同步实现（ HashMap他是非线程安全的实现）

    – Collections.synchronizedMap(Map m)（多线程下使用时：用该synchronizedMap封装方式先封装让他实现线程同步的）

    – 返回SynchronizedMap对象

内部实现如下：就是实现对set与get进行加锁，进行互斥上同步，不管读还是写都会拿到这个互斥对象。他变成很重的对象，不管读还是写，都会互斥阻塞，读堵塞写，写堵塞读，当多个读和写时线程会一个一个的进来。

public V get(Object key) {
    synchronized (mutex) {return m.get(key);}
 }
public V put(K key, V value) {
    synchronized (mutex) {return m.put(key, value);}
}

? ConcurrentHashMap（高性能的hash表，他就是做了减少锁粒度的实现，他被拆分好像16个Segment，每个Segment就是一个个小的hashmap.。就是把大的hash表拆成若干个小的hash表。）

– 若干个Segment ：Segment[] segments

– Segment中维护HashEntry

– put操作时? 先定位到Segment，锁定一个Segment，执行put

在减小锁粒度后， ConcurrentHashMap允许若干个线程同时进入

五、锁分离

就是把读堵塞写，写堵塞读，读读堵塞，写写堵塞就可以使用所分离；锁分离，就是读写锁分离，读不用改变数据，所以所有的读不会产生堵塞。当写的时候才去进行堵塞。一般读情况大于锁，所以使用读写锁会有所提高系统性能。如下图

1、? ReadWriteLock ：维护了一对锁，读锁可允许多个读线程并发使用，写锁是独占的。

  根据功能进行锁分离

所有读写锁的实现必须确保写操作对读操作的内存影响。换句话说，一个获得了读锁的线程必须能看到前一个释放的写锁所更新的内容。

读写锁比互斥锁允许对于共享数据更大程度的并发。每次只能有一个写线程，但是同时可以有多个线程并发地读数据。ReadWriteLock适用于读多写少的并发情况。 

读多写少的情况，可以提高性能（根据功能模块是进行不同锁，读锁跟读锁同时进入情况其实就属于无等待的并发，因此这种操作就是把堵塞的变成非堵塞的，性能就是有所改变）

锁	读锁	写锁
读锁	可访问	不可访问
写锁	不可访问	不可访问

ReadWriteLock源码剖析：https://blog.csdn.net/qq_19431333/article/details/70568478

2、读写分离思想可以延伸，只要操作互不影响，锁就可以分离

  LinkedBlockingQueue     LinkedBlockingQueue 用法：https://www.cnblogs.com/edgedance/p/7082078.html

    – 队列

    – 链表

思想也可以理解为：在forkjioning有所提到，就是任务work的偷窃，当线程执行自己的任务，和一个线程去盗取别人的任务，他们的任务队列中的数据他们是从两个不同的端去拿的，这就是热点分离基本思想，一个从头部拿，一个从尾部拿。如下：

头部和尾部之间的操作是不冲突的，所以可以进行高并发操作，当然当队列中只有一个数据情况就另当别论你了。

六、锁粗化

（一）、通常情况下，为了保证多线程间的有效并发，会要求每个线程持有锁的时间尽量短，即在使用完公共资源后，应该立即释放锁。只有这样，等待在这个锁上的其他线程才能尽早的获得资源执行任务。但是，凡事都有一个度，如果对同一个锁不停的进行请求、同步和释放，其本身也会消耗系统宝贵的资源，反而不利于性能的优化。

因此可以把很多次请求的锁拿到一个锁里面，但前提是：中间不需要的同步的代码块很很快的执行完。

1.举例如下：

public void demoMethod(){
  synchronized(lock){
    //do sth.
  }
  //做其他不需要的同步的工作，但能很快执行完毕
  synchronized(lock){
    //do sth.
  }
}

改进优化如下：

public void demoMethod(){
  //整合成一次锁请求
  synchronized(lock){
    //do sth.
    //做其他不需要的同步的工作，但能很快执行完毕
  }
}

2.举例如下：

for(int i=0;i<CIRCLE;i++){
  synchronized(lock){
  }
}

该进入下：

synchronized(lock){
  for(int i=0;i<CIRCLE;i++){
  }
}

七、锁消除

在即时编译器时，如果发现不可能被共享的对象，则可以消除这些对象的锁操作。

有时候对完全不可能加锁的代码执行了锁操作，因为些锁并不是我们加的，是JDK的类引用进来的，当我们使用的时候，会自动引进来，所以我们会在不可能出现在多线程需要同步的情况就执行了锁操作。在某些条件成熟下，系统会消除这些锁。如下：

public static void main(String args[]) throws InterruptedException {
    long start = System.currentTimeMillis();
    for (int i = 0; i < CIRCLE; i++) {
        craeteStringBuffer("JVM", "Diagnosis");
    }
    long bufferCost = System.currentTimeMillis() - start;
    System.out.println("craeteStringBuffer: " + bufferCost + " ms");
}
public static String craeteStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();  //他就是实现的多线程同步功能
    sb.append(s1);  //这两个就是同步操作
    sb.append(s2);
    return sb.toString();
}

sb是线程安全的。但事实上sb他在栈空间引用的，他是局部变量，他就是在线程内部才会有的，在局部变量表中，只有一个线程可以执行他，其他线程是不可靠，能访问到他的因此对sb进行所有同步操作都是无意义的。

因此对些情况，虚拟机提供了一些优化，就是如下操作，虚拟机开启server模式

同时进行开启逃逸分析DoEscapeAnalysis，如果没有逃逸的就把锁去掉(EliminateLocks)。逃逸分析是指：看sb是否有可能逃出StringBuffer的作用域。变成sb公有的，全局的变量，变成其他线程可访问的了。

进行逃逸分析的执行时间，（同时加上去掉锁操作），

进行逃逸分析的执行时间，（没有加上去掉锁操作）。

server模式用法简单讲解：

与client模式相比，server模式的启动比较慢，因为server模式会尝试收集更多的系统性能信息，使用更复杂的优化算法对程序进行优化。因此当系统完全启动并进入运行稳定期后，server模式的执行速度会远远快于client模式，所以在对于后台长期运行的系统，使用-server参数启动对系统的整体性能可以有不小的帮助，但对于用户界面程序，运行时间不长，又追求启动速度建议使用-client模式启动。

未来发展64位系统必然取代32位系统，而64位系统中的虚拟机更倾向于server模式。

八、虚拟机内的锁优化

? 偏向锁

? 轻量级锁

? 自旋锁

1.首先看下：对象头Mark 详细讲解：https://blog.csdn.net/zhoufanyang_china/article/details/54601311

? Mark Word，对象头的标记，32位 （对象头部保存一些对象的一些信息，32位是指系统的位数）

 描述对象的hash、锁信息，垃圾回收标记，年龄

    – 指向锁记录的指针

    – 指向monitor的指针

    – GC标记

    – 偏向锁线程ID

2、偏向锁（偏心，就是偏向当前占有锁的线程，他的思想是悲观的思想，一般我们都是杞人忧天的，大多情况是没有竞争的，就可以使用偏向锁，可以对一个线程操作提高性能）

思想：那么只需要在锁第一次被拥有的时候，记录下偏向线程ID。这样偏向线程就一直持有着锁，直到竞争发生才释放锁。以后每次同步，检查锁的偏向线程ID与当前线程ID是否一致，如果一致直接进入同步，退出同步也，无需每次加锁解锁都去CAS更新对象头，如果不一致意味着发生了竞争，锁已经不是总是偏向于同一个线程了，这时候需要锁膨胀为轻量级锁，才能保证线程间公平竞争锁。

在没有实际竞争的情况下，还能够针对部分场景继续优化。如果不仅仅没有实际竞争，自始至终，使用锁的线程都只有一个，那么，维护轻量级锁都是浪费的。偏向锁的目标是，减少无竞争且只有一个线程使用锁的情况下，使用轻量级锁产生的性能消耗。轻量级锁每次申请、释放锁都至少需要一次CAS，但偏向锁只有初始化时需要一次CAS。

“偏向”的意思是，偏向锁假定将来只有第一个申请锁的线程会使用锁（不会有任何线程再来申请锁），因此，只需要在Mark Word中CAS记录owner（本质上也是更新，但初始值为空），如果记录成功，则偏向锁获取成功，记录锁状态为偏向锁，以后当前线程等于owner就可以零成本的直接获得锁；否则，说明有其他线程竞争，膨胀为轻量级锁。

偏向锁无法使用自旋锁优化，因为一旦有其他线程申请锁，就破坏了偏向锁的假定。

（1.）大部分情况是没有竞争的，所以可以通过偏向来提高性能

（2.）所谓的偏向，就是偏心，即锁会偏向于当前已经占有锁的线程

（3.）将对象头Mark的标记设置为偏向，并将线程ID写入对象头Mark

（4.）只要没有竞争，获得偏向锁的线程，在将来进入同步块，不需要做同步

（5.）当其他线程请求相同的锁时，偏向模式结束

（6.） -XX:+UseBiasedLocking

? –默认启用

（6.）在竞争激烈的场合，偏向锁会增加系统负担（每次偏向模式都会失败，因为线程竞争，就会是偏向锁结束；所以每一次都很容易结束偏向锁，就加大了偏向锁的每一次判断，偏向锁就没有任何效果）

public static List<Integer> numberList =new Vector<Integer>();   //Vector带有锁
public static void main(String[] args) throws InterruptedException {
  long begin=System.currentTimeMillis();
  int count=0;
  int startnum=0;
  while(count<10000000){
  numberList.add(startnum);
  startnum+=2;
  count++;
  }
  long end=System.currentTimeMillis();
  System.out.println(end-begin);
}

在系统起来时虚拟机默认启用偏向时间是4，因为开始的竞争是很激烈的。

3.轻量级锁（就是如果在偏向锁失败时，系统就会有可能去进行轻量级锁，目的是尽可能不要动用操作系统中层面的互斥，性能差，因为对于操作系统来说，虚拟机本身就是应用，所以我们在应用层面去解决线程同步问题。）

自旋锁的目标是降低线程切换的成本。如果锁竞争激烈，我们不得不依赖于重量级锁，让竞争失败的线程阻塞；如果完全没有实际的锁竞争，那么申请重量级锁都是浪费的。轻量级锁的目标是，减少无实际竞争情况下，使用重量级锁产生的性能消耗，包括系统调用引起的内核态与用户态切换、线程阻塞造成的线程切换等。

顾名思义，轻量级锁是相对于重量级锁而言的。使用轻量级锁时，不需要申请互斥量，仅仅将Mark Word中的部分字节CAS更新指向线程栈中的Lock Record，如果更新成功，则轻量级锁获取成功，记录锁状态为轻量级锁；否则，说明已经有线程获得了轻量级锁，目前发生了锁竞争（不适合继续使用轻量级锁），接下来膨胀为重量级锁。

Mark Word是对象头的一部分；每个线程都拥有自己的线程栈（虚拟机栈），记录线程和函数调用的基本信息。二者属于JVM的基础内容，此处不做介绍。

当然，由于轻量级锁天然瞄准不存在锁竞争的场景，如果存在锁竞争但不激烈，仍然可以用自旋锁优化，自旋失败后再膨胀为重量级锁。

思想就是：判断线程是否持有某个对象锁，去看他的头部是否设置了这个对象的mark值，如果有，就说明线程拥有了锁。

? BasicObjectLock

    – 嵌入在线程栈中的对象

? 普通的锁处理性能不够理想，轻量级锁是一种快速的锁定方法。

? 如果对象没有被锁定(判断步骤)

– 将对象头的Mark指针保存到锁对象中

– 将对象头设置为指向锁的指针（在线程栈空间中）

如下操作：在虚拟机层面去进行快速持有锁与非持有锁判断操作，其实就是CAS操作。cas成功，说明你持有锁，费则则没有。

lock->set_displaced_header(mark);
if (mark == (markOop) Atomic::cmpxchg_ptr(lock, obj()->mark_addr(), mark))
{
 TEVENT (slow_enter: release stacklock) ;
 return ;
}

lock位于线程栈中

产生问题:

如果轻量级锁获取失败（CAS失败），表示存在竞争，升级为重量级锁（常规锁）
在没有锁竞争的前提下，减少传统锁使用OS（操作系统）互斥量产生的性能损耗

3.在竞争激烈时，轻量级锁会多做很多额外操作，导致性能下降

扩展CAS：

CAS:Compare and Swap, 翻译成比较并交换。

java.util.concurrent包中借助CAS实现了区别于synchronouse同步锁的一种乐观锁。

CAS操作包含三个操作数——内存位置（V），预期原值（A）和新值（B）。如果内存位置的值与预期原值相匹配，那么处理器将会自动将该位置值更新为新值，否则，不做任何操作。无论哪种情况，它都会在CAS指令之前返回该位置的值。

通过以上定义我们知道CAS其实是有三个步骤的

1.读取内存中的值

2.将读取的值和预期的值比较

3.如果比较的结果符合预期，则写入新值

https://blog.csdn.net/liu88010988/article/details/50799978
https://blog.csdn.net/qq_35357656/article/details/78657373

4.自旋锁（可以防止在操作系统层面线程被挂起）当轻量级锁没有拿到失败时，他就有可能动用操作系统方面的互斥，有可能动用是指，他还可能进行自旋锁操作。

当竞争存在时，如果线程可以很快获得锁，那么可以不在OS层挂起线程，让线程做几个空操作（自旋）;当拿不到锁时，不立即去挂掉线程，而是做空循环，尝试再去拿到锁，当别人释放锁时，你就可以拿到锁。避免线程在操作系统层面挂起。避免8万个时间周期的浪费。

? JDK1.6中-XX:+UseSpinning开启 1.6可关闭和开启操作，

? JDK1.7中，去掉此参数，改为内置实现 1.7则把他改为内置开启

? 如果同步块很长，自旋失败，会降低系统性能

? 如果同步块很短，自旋成功，节省线程挂起切换时间，提升系统性能

因此减少锁的持有时间也会增加自旋成功率。ConcurrentHashMap就可以使用这个自旋锁，hashmap的操作是非常快的，所以自旋等待的可能性就会提高。

5.偏向锁，轻量级锁，自旋锁总结（这些都是在虚拟机层面的优化，不是java层面的方式）

? 他们不是Java语言层面的锁优化方法，是虚拟机层面的方法

? 内置于JVM中的获取锁的优化方法和获取锁的步骤

– 偏向锁可用会先尝试偏向锁

– 轻量级锁可用会先尝试轻量级锁

– 以上都失败，尝试自旋锁

– 再失败，尝试普通锁，使用OS互斥量在操作系统层挂起  OS互斥量：

（1）、偏向锁、轻量级锁、重量级锁适用于不同的并发场景：

偏向锁：无实际竞争，且将来只有第一个申请锁的线程会使用锁。
轻量级锁：无实际竞争，多个线程交替使用锁；允许短时间的锁竞争。
重量级锁：有实际竞争，且锁竞争时间长。
另外，如果锁竞争时间短，可以使用自旋锁进一步优化轻量级锁、重量级锁的性能，减少线程切换。

如果锁竞争程度逐渐提高（缓慢），那么从偏向锁逐步膨胀到重量锁，能够提高系统的整体性能。

三种锁的详细解析：https://blog.csdn.net/zqz_zqz/article/details/70233767

https://blog.csdn.net/noble510520/article/details/78834224

6.一个错误使用锁的案例-对不变模式的数据类型进行加锁操作

public class IntegerLock {
    static Integer i=0;  
    public static class AddThread extends Thread{
    public void run(){
      for(int k=0;k<100000;k++){
        synchronized(i){
            i++;
        }
     }
        }
    }
  public static void main(String[] args) throws InterruptedException {
    AddThread t1=new AddThread();
    AddThread t2=new AddThread();
    t1.start();t2.start();
    t1.join();t2.join();
    System.out.println(i);
  }
}

interge 是不变模式的，也就是i值不会发生变化，变化的是i的引用。static Integer i=0; 是不变的，Interge是不可变的，对他i++是不会改变的，因此这里i++实际的动作是对原始的int做操作，对Interge做++其内部是对他自动拆箱成int进行i++的，这时候改变的不是interge对象的值，而是改变i本身的引用，当i++时，会生成新的Interge，并复到i上，而不是把原来i进行操作，如果每一次都对i做同步，但不同的线程操作的i对象可能不是同一个i，第一个可能执行原来的i,下一个线程可能执行新的i对象。（可以用上面代码测试）

7.ThreadLocal用法案例

ThreadLocal跟锁是没有关系，ThreadLocal是最彻底的，可以把锁完全给替代的东西。

基本思想是：多线程中对有数据冲突的对象进行加锁操作，那么去掉锁的简单方法是，为每一个线程都提供一个对象的实例，不同的线程访问自己的对象。

他是线程局部的变量

private static final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
public static class ParseDate implements Runnable{
int i=0;
public ParseDate(int i){this.i=i;}
public void run() {
try {
Date t=sdf.parse("2015-03-29 19:29:"+i%60);  //sdf对象他不是线程安全的
System.out.println(i+":"+t);
} catch (ParseException e) {
e.printStackTrace();
}
}
}
public static void main(String[] args) {
ExecutorService es=Executors.newFixedThreadPool(10);
for(int i=0;i<1000;i++){
es.execute(new ParseDate(i));
}
}

SimpleDateFormat被多线程访问

优化：线程安全的

static ThreadLocal<SimpleDateFormat> tl=new ThreadLocal<SimpleDateFormat>();
public static class ParseDate implements Runnable{
int i=0;
public ParseDate(int i){this.i=i;}
public void run() {
try {
if(tl.get()==null){
tl.set(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));//每一次要new一个对象
}
Date t=tl.get().parse("2015-03-29 19:29:"+i%60);
System.out.println(i+":"+t);
} catch (ParseException e) {
e.printStackTrace();
}
}
}
public static void main(String[] args) {
ExecutorService es=Executors.newFixedThreadPool(10);
for(int i=0;i<1000;i++){
es.execute(new ParseDate(i));
}
}

为每一个线程分配一个实例

另外一个错误案例：他不会去维护每一个对象的拷贝，实际上tl.get()是把ThreadLocal对象指向同一个对象实例，对所有线程来说他还是同一个对象。

static ThreadLocal<SimpleDateFormat> tl=new ThreadLocal<SimpleDateFormat>();
private static final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
public static class ParseDate implements Runnable{
int i=0;
public ParseDate(int i){this.i=i;}
public void run() {
try {
if(tl.get()==null){
tl.set(sdf);
}
Date t=tl.get().parse("2015-03-29 19:29:"+i%60);//这个还不是线程安全的，操作还是同一个线程，ThreadLocal指定的还是同一个对象，
System.out.println(i+":"+t);
} catch (ParseException e) {
e.printStackTrace();
}
}
}
public static void main(String[] args) {
ExecutorService es=Executors.newFixedThreadPool(10);
for(int i=0;i<1000;i++){
es.execute(new ParseDate(i));
}
}

如果使用共享实例，起不到效果

总结：对于工具等api对象类，数据库连接实例等希望对每个线程持单独有一个对象，就会减少线程的开销，比如SimpleDateFormat

不需要线程之间相互影响，不会产生冲突，就可以使用他。

ThreadLocal源码分析：https://www.cnblogs.com/dolphin0520/p/3920407.html