jvm锁优化

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

为什么会越界呢？

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

2.对象头Mark

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

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

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

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

------GC标记

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

3.偏向锁

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

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

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

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

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

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

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

4.轻量级锁

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

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

--如果对象没有被锁定

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

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

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

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

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

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

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

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

5.自旋锁

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

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

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

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

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

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

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

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

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

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

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

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

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

7.锁优化

 

减少锁持有时间

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

 

减小锁粒度

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

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

--HashMap的同步实现

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

--ConcurrentHashMap

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

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

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

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

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

 

锁分离

--根据功能进行锁分离

--ReadWriteLock

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

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

--LinkedBlockingQueue

------队列

------链表

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

 

锁粗化

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

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

锁消除

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

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关闭锁消除

8.无锁

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

--无锁的一种实现方式

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

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

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

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

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

这里简单介绍一下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的含义如下

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

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

下面介绍CAS引起的ABA问题

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

head.compareAndSet(A,B);

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

而对象B已经处于游离状态了

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

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

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

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