Java锁优化思路及JVM实现

1. 锁优化的思路和方法

这里提到的锁优化，是指在阻塞式的情况下，如何让性能不要变得太差。但是再怎么优化，一般来说性能都会比无锁的情况差一点。

这里要注意的是，在ReentrantLock中的tryLock，偏向于一种无锁的方式，因为在tryLock判断时，并不会把自己挂起。

锁优化的思路和方法总结一下，有以下几种。

  • 减少锁持有时间
  • 减小锁粒度
  • 锁分离
  • 锁粗化
  • 锁消除
    #### 1.1 减少锁持有时间
public synchronized void syncMethod(){
    othercode1();
    mutextMethod();
    othercode2();
}

像上述代码这样，在进入方法前就要得到锁，其他线程就要在外面等待。

这里优化的一点在于，要减少其他线程等待的时间，所以，只用在有线程安全要求的程序上加锁

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

1.2 减小锁粒度

将大对象（这个对象可能会被很多线程访问），拆成小对象，大大增加并行度，降低锁竞争。降低了锁的竞争，偏向锁，轻量级锁成功率才会提高。

最最典型的减小锁粒度的案例就是ConcurrentHashMap(当然也是1.8之前了)。

1.3 锁分离

最常见的锁分离就是读写锁ReadWriteLock，根据功能进行分离成读锁和写锁，这样读读不互斥，读写互斥，写写互斥，即保证了线程安全，又提高了性能。

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

比如LinkedBlockingQueue：

从头部取出，从尾部放数据。

1.4 锁粗化

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

举个例子：

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

这种情况，根据锁粗化的思想，应该合并:

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

当然这是有前提的，前提就是中间的那些不需要同步的工作是很快执行完成的。

再举一个极端的例子：

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

    }
}

在一个循环内不同得获得锁。虽然JDK内部会对这个代码做些优化，但是还不如直接写成:

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

    }
}

当然如果有需求说，这样的循环太久，需要给其他线程不要等待太久，那只能写成上面那种。如果没有这样类似的需求，还是直接写成下面那种比较好。

1.5 锁消除

锁消除是在编译器级别的事情。

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

也许你会觉得奇怪，既然有些对象不可能被多线程访问，那为什么要加锁呢？写代码时直接不加锁不就好了。

但是有时，这些锁并不是程序员所写的，有的是JDK实现中就有锁的，比如Vector和StringBuffer这样的类，它们中的很多方法都是有锁的。当我们在一些不会有线程安全的情况下使用这些类的方法时，达到某些条件时，编译器会将锁消除来提高性能。

比如：

public static void main(String args[]) throws InterruptedException {
    long start = System.currentTimeMillis();
    for (int i = 0; i < 2000000; i++) {
        createStringBuffer("JVM", "Diagnosis");
    }
    long bufferCost = System.currentTimeMillis() - start;
    System.out.println("craeteStringBuffer: " + bufferCost + " ms");
}

public static String createStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb.toString();
}

上述代码中的StringBuffer.append是一个同步操作，但是StringBuffer却是一个局部变量，并且方法也并没有把StringBuffer返回，所以不可能会有多线程去访问它。

那么此时StringBuffer中的同步操作就是没有意义的。

开启锁消除是在JVM参数上设置的，当然需要在server模式下：

-server -XX:+DoEscapeAnalysis -XX:+EliminateLocks

并且要开启逃逸分析。 逃逸分析的作用呢，就是看看变量是否有可能逃出作用域的范围。

比如上述的StringBuffer，上述代码中craeteStringBuffer的返回是一个String，所以这个局部变量StringBuffer在其他地方都不会被使用。如果将craeteStringBuffer改成:

public static StringBuffer craeteStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb;
}

那么这个 StringBuffer被返回后，是有可能被任何其他地方所使用的（譬如被主函数将返回结果put进map啊等等）。那么JVM的逃逸分析可以分析出，这个局部变量 StringBuffer逃出了它的作用域。

所以基于逃逸分析，JVM可以判断，如果这个局部变量StringBuffer并没有逃出它的作用域，那么可以确定这个StringBuffer并不会被多线程所访问，那么就可以把这些多余的锁给去掉来提高性能。

2. 虚拟机内的锁优化

先要介绍下对象头，在JVM中，每个对象都有一个对象头。Mark Word，对象头的标记，32位（32位系统）。描述对象的hash、锁信息，垃圾回收标记，年龄。会保存指向锁记录的指针，指向monitor的指针，偏向锁线程ID等。简单来说，对象头就是要保存一些系统性的信息。

2.1 偏向锁

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

大部分情况是没有竞争的（某个同步块大多数情况都不会出现多线程同时竞争锁），所以可以通过偏向来提高性能。即在无竞争时，之前获得锁的线程再次获得锁时，会判断是否偏向锁指向我，那么该线程将不用再次获得锁，直接就可以进入同步块。

偏向锁的实施就是将对象头Mark的标记设置为偏向，并将线程ID写入对象头Mark。

当其他线程请求相同的锁时，偏向模式结束。

JVM默认启用偏向锁 -XX:+UseBiasedLocking

在竞争激烈的场合，偏向锁会增加系统负担（每次都要加一次是否偏向的判断）

偏向锁的例子：

public static List<Integer> numberList = new Vector<Integer>();

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);
}

Vector是一个线程安全的类，内部使用了锁机制。每次add都会进行锁请求。上述代码只有main一个线程再反复add请求锁。

使用如下的JVM参数来设置偏向锁：

-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0

BiasedLockingStartupDelay表示系统启动几秒钟后启用偏向锁。默认为4秒，原因在于，系统刚启动时，一般数据竞争是比较激烈的，此时启用偏向锁会降低性能。

下面关闭偏向锁：

-XX:-UseBiasedLocking

2.2 轻量级锁

Java的多线程安全是基于Lock机制实现的，而Lock的性能往往不如人意。

原因是，monitorenter与monitorexit这两个控制多线程同步的bytecode原语，是JVM依赖操作系统互斥(mutex)来实现的。

互斥是一种会导致线程挂起，并在较短的时间内又需要重新调度回原线程的，较为消耗资源的操作。

为了优化Java的Lock机制，从Java6开始引入了轻量级锁的概念。

轻量级锁（Lightweight Locking）本意是为了减少多线程进入互斥的几率，并不是要替代互斥。

它利用了CPU原语Compare-And-Swap(CAS，汇编指令CMPXCHG)，尝试在进入互斥前，进行补救。

如果偏向锁失败，那么系统会进行轻量级锁的操作。它存在的目的是尽可能不用动用操作系统层面的互斥，因为那个性能会比较差。因为JVM本身就是一个应用，所以希望在应用层面上就解决线程同步问题。总结一下就是轻量级锁是一种快速的锁定方法，在进入互斥之前，使用CAS操作来尝试加锁，尽量不要用操作系统层面的互斥，提高了性能。

如果轻量级锁失败，表示存在竞争，升级为重量级锁（常规锁），就是操作系统层面的同步方法。在没有锁竞争的情况，轻量级锁减少传统锁使用OS互斥量产生的性能损耗。在竞争非常激烈时（轻量级锁总是失败），轻量级锁会多做很多额外操作，导致性能下降。

2.3 自旋锁

当竞争存在时，因为轻量级锁尝试失败，之后有可能会直接升级成重量级锁动用操作系统层面的互斥。也有可能再尝试一下自旋锁。

如果线程可以很快获得锁，那么可以不在OS层挂起线程，让线程做几个空操作（自旋），并且不停地尝试拿到这个锁（类似tryLock），当然循环的次数是有限制的，当循环次数达到以后，仍然升级成重量级锁。所以在每个线程对于锁的持有时间很少时，自旋锁能够尽量避免线程在OS层被挂起。

JDK1.6中-XX:+UseSpinning开启

JDK1.7中，去掉此参数，改为内置实现

如果同步块很长，自旋失败，会降低系统性能。如果同步块很短，自旋成功，节省线程挂起切换时间，提升系统性能。

2.4 偏向锁，轻量级锁，自旋锁总结

上述的锁不是Java语言层面的锁优化方法，是内置在JVM当中的。

首先偏向锁是为了避免某个线程反复获得/释放同一把锁时的性能消耗，如果仍然是同个线程去获得这个锁，尝试偏向锁时会直接进入同步块，不需要再次获得锁。

而轻量级锁和自旋锁都是为了避免直接调用操作系统层面的互斥操作，因为挂起线程是一个很耗资源的操作。

为了尽量避免使用重量级锁（操作系统层面的互斥），首先会尝试轻量级锁，轻量级锁会尝试使用CAS操作来获得锁，如果轻量级锁获得失败，说明存在竞争。但是也许很快就能获得锁，就会尝试自旋锁，将线程做几个空循环，每次循环时都不断尝试获得锁。如果自旋锁也失败，那么只能升级成重量级锁。

可见偏向锁，轻量级锁，自旋锁都是乐观锁。

3. 一个错误使用锁的案例

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);
    }
}

一个很初级的错误在于，Interger是final不变的，每次++后，会产生一个新的 Interger再赋给i，所以两个线程争夺的锁是不同的。所以并不是线程安全的。

4. ThreadLocal及其源码分析

这里来提ThreadLocal可能有点不合适，但是ThreadLocal是可以把锁代替的方式。所以还是有必要提一下。

基本的思想就是，在一个多线程当中需要把有数据冲突的数据加锁，使用ThreadLocal的话，为每一个线程都提供一个对象实例。不同的线程只访问自己的对象，而不访问其他的对象。这样锁就没有必要存在了。

由于SimpleDateFormat并不线程安全的，直接在多线程下使用是错误的。最简单的方式就是，自己定义一个类去用synchronized包装（类似于Collections.synchronizedMap）。这样做在高并发时会有问题，对 synchronized的争用导致每一次只能进去一个线程，并发量很低。

这里使用ThreadLocal去封装SimpleDateFormat就解决了这个问题:

public class Test {
    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"));
                }
                Date t = tl.get().parse("2016-02-16 17:00:" + 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));
        }
    }

}

每个线程在运行时，会判断是否当前线程有SimpleDateFormat对象:

if (tl.get() == null)

如果没有的话，就new个 SimpleDateFormat与当前线程绑定:

tl.set(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));

然后用当前线程的 SimpleDateFormat去解析:

tl.get().parse("2016-02-16 17:00:" + i % 60);

一开始的代码中，只有一个 SimpleDateFormat，使用了 ThreadLocal，为每一个线程都new了一个 SimpleDateFormat。

需要注意的是，这里不要把公共的一个SimpleDateFormat设置给每一个ThreadLocal，这样是没用的。 需要给每一个都new一个SimpleDateFormat。

在hibernate中，对ThreadLocal有典型的应用。

下面来看一下ThreadLocal的源码实现

首先Thread类中有一个成员变量:

ThreadLocal.ThreadLocalMap threadLocals = null;

而这个Map就是ThreadLocal的实现关键:

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
}

根据 ThreadLocal可以set和get相对应的value。

这里的ThreadLocalMap实现和HashMap差不多，但是在hash冲突的处理上有区别。

ThreadLocalMap中发生hash冲突时，不是像HashMap这样用链表来解决冲突，而是是将索引++，放到下一个索引处来解决冲突。

原文地址：https://www.cnblogs.com/john8169/p/9313848.html

时间： 2024-10-12 03:05:43

Java锁优化思路及JVM实现的相关文章

java锁优化

一.锁优化的思路和方法 锁优化是指:在多线程的并发中当用到锁时,尽可能让性能有所提高.一般并发中用到锁,就是阻塞的并发,前面讲到一般并发级别分为阻塞的和非阻塞的(非阻塞的包含:无障碍的,无等待的,无锁的等等),一旦用到锁,就是阻塞的,也就是一般最糟糕的并发,因此锁优化就是在堵塞的情况下去提高性能:所以所锁的优化就是让性能尽可能提高,不管怎么提高,堵塞的也没有无锁的并发底.让锁定的障碍降到最低,锁优化并不是说就能解决锁堵塞造成的性能问题.这是做不到的. 方法如下: ? 减少锁持有时间 ? 减小锁粒

Java 锁优化

一.重量级锁 Java中,Synchronized是通过对象内部的一个叫做监视器锁(monitor)来实现的.但是监视器锁本质又是依赖于底层的操作系统的Mutex Lock来实现的.而操作系统实现线程之间的切换这就需要从用户态转换到核心态,这个成本非常高,状态之间的转换需要相对比较长的时间,这就是为什么Synchronized效率低的原因.因此,这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”.JDK中对Synchronized做的种种优化,其核心都是为了减少这种重量级锁的

java多线程编程——锁优化

并发环境下进行编程时,需要使用锁机制来同步多线程间的操作,保证共享资源的互斥访问.加锁会带来性能上的损坏,似乎是众所周知的事情.然而,加锁本身不会带来多少的性能消耗,性能主要是在线程的获取锁的过程.如果只有一个线程竞争锁,此时并不存在多线程竞争的情况,那么JVM会进行优化,那么这时加锁带来的性能消耗基本可以忽略.因此,规范加锁的操作,优化锁的使用方法,避免不必要的线程竞争,不仅可以提高程序性能,也能避免不规范加锁可能造成线程死锁问题,提高程序健壮性.下面阐述几种锁优化的思路. 一.尽量不要锁住方

jvm(13)-线程安全与锁优化（转）

0.1)本文部分文字转自“深入理解jvm”, 旨在学习 线程安全与锁优化 的基础知识: 0.2)本文知识对于理解 java并发编程非常有用,个人觉得,所以我总结的很详细: [1]概述 [2]线程安全 1)线程安全定义:当多个线程访问一个对象时,如果不用考虑这些线程在运行时环境下的调度和交替执行,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作,调用这个对象的行为都可以获得正确的结果,那这个对象是线程安全的:(干货——线程安全定义) [2.1]java 语言中的线程安全(干货——java

Java多线程编程—锁优化

并发环境下进行编程时,需要使用锁机制来同步多线程间的操作,保证共享资源的互斥访问.加锁会带来性能上的损坏,似乎是众所周知的事情.然而,加锁本身不会带来多少的性能消耗,性能主要是在线程的获取锁的过程.如果只有一个线程竞争锁,此时并不存在多线程竞争的情况,那么JVM会进行优化,那么这时加锁带来的性能消耗基本可以忽略.因此,规范加锁的操作,优化锁的使用方法,避免不必要的线程竞争,不仅可以提高程序性能,也能避免不规范加锁可能造成线程死锁问题,提高程序健壮性.下面阐述几种锁优化的思路. 一.尽量不要锁住方

Java并发编程：synchronized和锁优化

每天学习一点点 编程PDF电子书.视频教程免费下载:http://www.shitanlife.com/code 1. 使用方法 synchronized 是 java 中最常用的保证线程安全的方式,synchronized 的作用主要有三方面: 确保线程互斥的访问代码块,同一时刻只有一个方法可以进入到临界区 保证共享变量的修改能及时可见 有效解决重排序问题 语义上来讲,synchronized主要有三种用法: 修饰普通方法,锁的是当前对象实例(this) 修饰静态方法,锁的是当前 Class

JVM锁优化

1.锁优化 挂起线程和恢复线程的开销较大,对于锁定状态时间较短的情况下,挂起线程并不值得. 自旋锁与它的自适应自旋 遇到锁不会挂起,而是忙循环(自旋)一会儿,避免了一次线程切换的开销,但是仍在占用CPU时间. 1.6默认开启,默认自旋10次. 1.6还引入了自适应自旋锁,他可以根据上一次在同一个锁上的自旋时间调整自旋次数. 自旋失败则进入正常的挂起线程. 锁消除 JIT即时编译器在运行时如果发现某块代码上有同步,但是检测到该共享区域不可能存在竞争,就会进行锁消除. 如对某个局部变量操作时加了锁,

深入理解Java虚拟机（第三版）-14. 线程安全与锁优化

14. 线程安全与锁优化 1. 什么是线程安全? 当多个线程同时访问一个对象时,如果不用考虑这些线程在运行时环境下的调度和交替进行,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作,调用这个对象的行为都可以获得正确的结果,那就称这个对象是线程安全的 2. Java语言中的线程安全 我们将Java语言下的线程安全分为以下五类:不可变.绝对线程安全.相对线程安全.线程兼容和线程对立. 1.不可变:不可变一定是线程安全的,无论是对象的方法实现还是方法的调用者,都不需要进行任何线程安全保障措施

一夜搞懂 | JVM 线程安全与锁优化

前言 本文已经收录到我的 Github 个人博客,欢迎大佬们光临寒舍: 我的 GIthub 博客 学习导图 一.为什么要学习内存模型与线程? 之前我们学习了内存模型和线程,了解了 JMM 和线程,初步探究了 JVM 怎么实现并发,而本篇文章,我们的关注点是 JVM 如何实现高效 并发编程的目的是为了让程序运行得更快,提高程序的响应速度,虽然我们希望通过多线程执行任务让程序运行得更快,但是同时也会面临非常多的挑战,比如像线程安全问题.线程上下文切换的问题.硬件和软件资源限制等问题,这些都是并发编程