JVM虚拟机---JVM锁机制

╰+哭是因爲堅強的太久メ 2022-05-14 00:44 332阅读 0赞

**1.线程安全**

如果你的代码所在的进程中有多个线程在同时运行，而这些线程可能会同时运行这段代码。如果每次运行结果和单线程运行的结果是一样的，而且其他的变量的值也和预期的是一样的，就是线程安全的。

\----使用锁，维护计数器的串行访问与安全性

import java.util.ArrayList;
    
    import java.util.List;
    
    
    public class TestAddToList implements Runnable{
    
    public static List<Integer> numberList = new ArrayList<Integer>();
    
    int startNum = 0;
    
    public TestAddToList(int startNum){
    
    this.startNum = startNum;
    
    }
    
    @Override
    
    public void run(){
    
    int count = 0;
    
    while(count < 1000000){
    
    numberList.add(startNum);
    
    startNum += 2;
    
    count++;
    
    }
    
    }
    
    public static void main(String[] args) throws Exception{
    
    Thread t1 = new Thread(new TestAddToList(0));
    
    Thread t2 = new Thread(new TestAddToList(1));
    
    t1.start();
    
    t2.start();
    
    while(t1.isAlive()||t2.isAlive()){
    
    Thread.sleep(1);
    
    }
    
    System.out.println(numberList.size());
    
    }
    
    }

![70][]

为什么会越界呢？

如果单线程是不会出现越界的情况的，因为list在不够用的时候回扩容，但是多线程来说，在list正要准备扩容的时候，理应不能对list进行操作的，但是没有相关代码进行处理，所以在扩容的时候， 有线程继续往里面添加元素，导致数组越界。

**2.对象头Mark**

\-Mark word, 对象头的标记，32位

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

\------指向锁记录的指针

\------指向monitor的指针

\------GC标记

\------偏向锁线程ID

**3.偏向锁**

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

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

\--将对象头mark的标记设置为偏向，并将线程ID写入对象头Mark

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

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

\--    -XX:+UseBiasedLocking  ----默认启用

\--在竞争激烈的场合，偏向锁会增加系统负担

**4.轻量级锁**

\--嵌入在**线程栈**中的对象

![70 1][]

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

\--如果对象没有被锁定

\------将对象头的mark指针保存到锁对象中

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

锁对象拥有对象头的mark指针，对象头拥有指向锁的指针。笼统来讲就是，线程栈指向对象头，对象头指向线程栈，一个循环引用的过程

![70 2][]

将对象头的mark备份到锁中，![70 3][] 比较交换，将lock对象本身放到对象头中去，即对象头拥有指向锁的指针，形成循环引用。

**如何判断线程持有这个锁，只需判断对象头的指针是不是指向线程栈中的锁的方向。**

\--如果轻量级锁失败，表示存在竞争，升级为重量级锁Monitor

\--在没有锁竞争的前提下，减少传统锁使用OS互斥量产生的性能损耗

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

**5.自旋锁**

线程在那边什么都不做，只是在做空循环循环体里面没有任何语句，也不挂起，等待一把锁。

\--当竞争存在时，如果线程可以很快获得锁，那么可以不再OS层挂起线程，让线程做几个空操作（自旋）

\--JDK1.6中-XX:+UseSpinning开启自旋锁

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

\--如果同步块很长，自旋失败，会降低系统性能，因为自旋目的是不需要线程挂起就能获得锁，我用空转指令代替线程挂起和恢复的开销，只要空转指令的成本小于，挂起和恢复的开销，就是合算的，如果自旋之后，我还拿不到锁，最终还是要挂起和恢复，那么自旋就是无用功，更加降低系统性能。

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

**6.偏向锁、轻量级锁、自旋锁的总结**

\--不是java语言层面的锁优化方法

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

\------偏向锁可用会优先尝试偏向锁

\------轻量级锁可用会先尝试轻量级锁

\------以上都失败，尝试自旋锁

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

**7.锁优化**

**减少锁持有时间**

![70 4][]

只对需要同步的块进行同步，这样有助于减少锁的持有时间， 就减少线程等待的时间，这样如果你需要自旋，那么自旋成功的概率就会增大，提升系统性能。

**减小锁粒度**

\--将大对象，拆成小对象，大大增加并行度，降低锁竞争

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

\--HashMap的同步实现

![70 5][]

一旦有put或者get操作，整个hashmap集合都会被锁住，这回让效率变慢，如下操作可以加快效率

\--ConcurrentHashMap

\------若干个Segment:Segment<K, V>\[\] segments

\------Segment中维护HashEntry<K, V>，相当于小的hashmap

\------put操作时，先定位到Segment，锁定一个Segment，执行put

普通hashmap里面只有一个大数组，如果进行put操作时，需要对大数组进行加锁，而—ConcurrentHashMap中有若干个数组，进行put操作时候，只需对小数组进行加锁

\--减小锁粒度之后，--ConcurrentHashMap允许若干线程同时进入

**锁分离**

\--根据功能进行锁分离

\--ReadWriteLock

\--读多写少的情况，可以提高性能

![70 6][]

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

\--LinkedBlockingQueue

\------队列

\------链表

![70 7][]

在多线程中，如果只使用一个锁，那么在take 的时候，需要锁住链表，put不能进行，在put的时候，也需要锁住链表，take不能进行，这样对于效率来说并不好，竞争也比较激烈。然后锁分离状况，take使用take锁，put使用put锁，take和put就可以同时进行，效率也会提高。

**锁粗化**

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

![70 8][]

修改前，两个同步块需要频繁拥有锁，而中间的**不需要同步的代码会很快执行完毕**，因此返回拥有和释放锁，会引起效率下降。应该将其整合成一块，从而减少拥有和释放锁的次数

![70 9][]

**锁消除**

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

public class TestLockClear{
    
    public static String createStringBuffer(String s1, String s2)
    
    {
    
    StringBuffer sb = new StringBuffer();
    
    sb.append(s1);
    
    sb.append(s2);
    
    return sb.toString();
    
    }
    
    
    public static void main(String[] args)
    
    {
    
    long start = System.currentTimeMills();
    
    for(int i = 0; i < 1000; i++)
    
    {
    
    createStringBuffer("JVM", "Diagnosis");
    
    }
    
    long bufferCost = System.currentTimeMills() - start;
    
    System.out.println("createStringBuffer: " + bufferCost + "ms");
    
    }
    
    }

StringBuffer本身是个线程安全的类，append方法是同步操作

上述createStringBuffer方法里面的sb是局部变量，不会引起线程不安全的问题，所以append方法里面的锁就是多余，会降低运行效率，可以将其通过下面命令进行锁消除

\-server –XX:+DoEscapeAnalysis –XX:+EliminateLocks开启锁消除

\-server –XX:+DoEscapeAnalysis –XX:-EliminateLocks关闭锁消除

![70 10][]

**8.无锁**

\--锁是悲观的操作，无锁是乐观的操作

\--无锁的一种实现方式

\------CAS（Compare and swap）

\------非阻塞的同步

\------CAS（V,E,N）v表示要更新的变量，E对V的一种期望值，N就是新的值

\------把新值N赋值给V，但是不是无条件的，当且仅当，V=E的时候

\--在应用层面判断多线程的干扰，如果有干扰，则通知线程重试

![70 11][]

这里简单介绍一下CAS，通过AtomicInteger说明

private volatile int value;
    
    
    //此处省略一万字代码
    
    
    /**
    
    * Atomically sets to the given value and returns the old value.
    
    * @param newValue the new value
    
    * @return the previous value
    
    */
    
    public final int getAndSet(int newValue) {
    
    for (;;) {
    
    int current = get();
    
    if (compareAndSet(current, newValue))
    
    return current;
    
    }
    
    }
    
    
    
    /**
    
    * Atomically sets the value to the given updated value
    
    * if the current value {@code ==} the expected value.
    
    * @param expect the expected value
    
    * @param update the new value
    
    * @return true if successful. False return indicates that
    
    * the actual value was not equal to the expected value.
    
    */
    
    public final boolean compareAndSet(int expect, int update) {
    
    return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    
    }

从这段代码可知，AtomicInteger中真正存储数据的是value变量，而value是被volatile修饰的，保证了线程的直接可见性

getAndSet方法通过一个死循环不断尝试复制操作，而真正复制操作交给了unsafe类实现，AtomicInteger的getAndSet调用了unsafe类的 unsafe.compareAndSwapInt(this, valueOffset, expect, update);，这个函数表明，如果expect与valueOffset的值一致，九江update赋值给valueOffset，而valueOffset的含义如下

![70 12][]

value存的是当前值，而当前值存放的内存地址可以通过valueOffset来确定，实际上是value字段相对于java对象的起始地址的偏移量。即CAS方法**通过对比“valueOffset上的value”与expect是否相同，来决定是否修改value值为update值**

既然是这样，虽然CAS是原子性操作，但是也不代表不会出问题，就是概率不太大

下面介绍CAS引起的ABA问题

![70 13][]

有一个单链表实现的堆栈，栈顶为A，线程1已知A.next=B,然后希望CAS将栈顶替换为B；

head.compareAndSet(A,B);

在线程1执行上面的指令之前，线程2介入，将A，B出栈，然后在pushD,C,A，，此时结构如下

![70 14][]而对象B已经处于游离状态了

此时，线程1执行CAS操作，检测时仍然发现栈顶为A，所以CAS成功，栈顶变为B，但实际上B.next为null，此时情况变为

![70 15][]

其中堆栈中只有B一个元素，C和D组成的链表已经不在堆栈中，平白无故把C,D丢了

针对这种情况，java并发包中提供了一个带有标记的原子引用类"AtomicStampedReference"，它可以通过控制变量值的版本来保证CAS的正确性。

当AtomicStampedReference对应的数值被修改时，除了更新数据本身外，还必须要更新时间戳。当AtomicStampedReference设置对象值时，对象值以及时间戳都必须满足期望值，写入才会成功。因此，即使对象值被反复读写，写回原值，只要时间戳发生变化，就能防止不恰当的写入。

[70]: /images/20220514/1e5da2b96a534f3a9a4a865fe95c2132.png
[70 1]: /images/20220514/3f91318134774dfabce8475dca3e53eb.png
[70 2]: /images/20220514/5a3abda62b514c75a8f5b2db5cac244f.png
[70 3]: /images/20220514/9bc82c7890ae4c04a283da0eb154a314.png
[70 4]: /images/20220514/747e2206b35b47d299222b0f4849d03b.png
[70 5]: /images/20220514/ce17a2e710f14e769076fd3c9b68cfa8.png
[70 6]: /images/20220514/22fd400530204f208ed0aa7a185b221b.png
[70 7]: /images/20220514/b0b1f6593aba4946b463b6a91e4a8d7c.png
[70 8]: /images/20220514/9987ff6b39aa4637997b2db0b0aafac1.png
[70 9]: /images/20220514/c97a628aae7f497cb6c3acccec3a7044.png
[70 10]: /images/20220514/d2cd21e71dde477e90dbf96edcefeba8.png
[70 11]: /images/20220514/1c2faa49beda483cbb70663effe67d4c.png
[70 12]: /images/20220514/1dec89a2d6ee4d81b1d99d9b0ea29faa.png
[70 13]: /images/20220514/37a7c2571f454d859d9a298db49605e6.png
[70 14]: /images/20220514/c80d6d96e8bd4a2da8dd433c9d971549.png
[70 15]: /images/20220514/4509771703684ac086a8db8d01744307.png