黑匣子
满天星
Fork me on GitHub

JVM内核-原理、诊断与优化学习笔记(九):锁

线程安全

多线程网站统计访问人数

使用锁,维护计数器的串行访问与安全性
当然如果网站的任务精确度要求不是很高,并发量不是很大,可以不加锁,以此提升性能,具体怎样取舍看实际情况

多线程访问ArrayList

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public static List<Integer> numberList =new ArrayList<Integer>();
public static class AddToList implements Runnable{
int startnum=0;
public AddToList(int startnumber){
startnum=startnumber;
}
@Override
public void run() {
int count=0;
while(count<1000000){
numberList.add(startnum);
startnum+=2;
count++;
}
}
}
1
2
3
4
5
6
7
8
9
10
public static void main(String[] args) throws InterruptedException {
Thread t1=new Thread(new AddToList(0));
Thread t2=new Thread(new AddToList(1));
t1.start();
t2.start();
while(t1.isAlive() || t2.isAlive()){
Thread.sleep(1);
}
System.out.println(numberList.size());
}

在这里插入图片描述
根据上上面的代码命名应该会有200000的容量,ArrayList是会自己扩容的,为什么最后报错ArrayIistOutOfBoundsException(下标越界)的错误呢?
ArrayList不是线程安全的,虽然它自己会扩容,但是如果它如果容量不够需要扩展的情况下,实际上它是一个不可用的状态,这个时候,如果另一个线程突然往里面插数据,又没有对ArrayList做线程保护, ArrayList本身是不可用的,因此抛出这个异常。

所以很可能线程不仅仅是不能精确统计的问题,很可能整个程序根本无法正常的执行。

对象头Mark

Mark Word,对象头的标记,32位

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

指向锁记录的指针
指向monitor的指针
GC标记
偏向锁线程ID

偏向锁

  • 大部分情况是没有竞争的,或者竞争不激烈的,所以可以通过偏向来提高性能
  • 所谓的偏向,就是偏心,即锁会偏向于当前已经占有锁的线程
  • 将对象头Mark的标记设置为偏向,并将线程ID写入对象头Mark
  • 只要没有竞争,获得偏向锁的线程,在将来进入同步块,不需要做同步
  • 当其他线程请求相同的锁时,偏向模式结束
  • -XX:+UseBiasedLocking 默认启用
  • 在竞争激烈的场合,偏向锁会增加系统负担
1
2
3
4
5
6
7
8
9
10
11
12
13
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是通过加锁保证线程安全的。

1
2
3
4
//打开偏向锁,因为jvm刚启动的时候竞争是比较激烈的,所以系统默认是过几秒钟在开启偏向锁的
//这里BiasedLockingStartupDelay=0是希望jvm刚起动就打开偏向锁
//因为这个程序执行的很快
-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0

1
2
//关闭偏向锁
-XX:-UseBiasedLocking

本例中,使用偏向锁,可以获得5%以上的性能提升

轻量级锁

BasicObjectLock

嵌入在 线程栈中的对象
在这里插入图片描述
BasicLock就是对象头,ptr to obj holdd the lock 指向持有这个锁的对象的指针

为什么要有轻量级锁

  • 普通的锁处理性能不够理想,轻量级锁是一种快速的锁定方法。
  • 如果对象没有被锁定
    将对象头的Mark指针保存到锁对象(BasicObjectLock)中
    将对象头设置为指向锁的指针(在线程栈空间中)
1
2
3
4
5
6
7
8
9
10
//锁里面有displaced_header(对象头)
lock->set_displaced_header(mark);
//对象交换,将lock(锁)本身放到对象头当中去
//如果成功了就表示锁拿到了,lock是位于线程栈中的,因此如何判断线程持有这个锁
//只需要判断对象头的指针,是不是在线程的栈当中,
//是就是持有这把锁,不是就没有持有这把锁
if (mark == (markOop) Atomic::cmpxchg_ptr(lock, obj()->mark_addr(), mark)) {
TEVENT (slow_enter: release stacklock) ;
return ;
}

如果轻量级锁失败,表示存在竞争,升级为重量级锁(常规锁)
在没有锁竞争的前提下,减少传统锁使用OS互斥量产生的性能损耗
在竞争激烈时,轻量级锁会多做很多额外操作(无用功),导致性能下降

自旋锁

当竞争存在时,如果线程可以很快获得锁,那么可以不在OS层挂起线程,让线程做几个空操作(自旋)
JDK1.6中-XX:+UseSpinning开启
JDK1.7中,去掉此参数,改为内置实现
如果同步块很长,需要自旋很久,还没有拿到锁,自旋失败,会降低系统性能
如果同步块很短,很快就拿到了锁,自旋成功,节省线程挂起切换时间,提升系统性能

偏向锁,轻量级锁,自旋锁总结

  • 不是Java语言层面的锁优化方法
  • 内置于JVM中的获取锁的优化方法和获取锁的步骤
    偏向锁可用会先尝试偏向锁
    轻量级锁可用会先尝试轻量级锁
    以上都失败,尝试自旋锁
    再失败,尝试普通锁,使用OS互斥量在操作系统层挂起

    线面开始是jvm级别的锁的优化

    减少锁持有时间

1
2
3
4
5
public synchronized void syncMethod(){
othercode1();
mutextMethod();
othercode2();
}

变成:

1
2
3
4
5
6
7
public void syncMethod2(){
othercode1();
synchronized(this){
mutextMethod();
}
othercode2();
}

没有必要做同步的就不要放到同步代码块中

减小锁粒度

  • 将大对象,拆成小对象,大大增加并行度,降低锁竞争
  • 偏向锁,轻量级锁成功率提高(因为希望在短时间内得到锁)
  • ConcurrentHashMap
  • HashMap的同步实现
    Collections.synchronizedMap(Map<K,V> m)
    返回SynchronizedMap对象
1
2
3
4
5
6
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
    若干个Segment :Segment<K,V>[] segments
    Segment中维护HashEntry<K,V>
    put操作时
    先定位到Segment,锁定一个Segment,执行put
  • 在减小锁粒度后, ConcurrentHashMap允许若干个线程同时进入

    小问题?

    减少锁粒度后,可能会带来什么负面影响呢?以ConcurrentHashMap为例,说明分割为多个
    Segment后,在什么情况下,会有性能损耗?

    锁分离

    根据功能进行锁分离
    ReadWriteLock
    读多写少的情况,可以提高性能
    在这里插入图片描述
    ArrayLIst在写的时候可能需要做一些扩展,这个时候禁止其他任何线程对它做访问。

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

  • LinkedBlockingQueue
    队列
    链表
    在这里插入图片描述
    take和put操作互补影响,就可以进行分离。

    锁粗化

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

    举个🌰

    1
    2
    3
    4
    5
    6
    7
    8
    9
    public void demoMethod(){
    synchronized(lock){
    //do sth.
    }
    //做其他不需要的同步的工作,但能很快执行完毕
    synchronized(lock){
    //do sth.
    }
    }

变成:

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

1
2
3
4
5
for(int i=0;i<CIRCLE;i++){
synchronized(lock){

}
}

变成:

1
2
3
4
5
synchronized(lock){
for(int i=0;i<CIRCLE;i++){

}
}

锁消除

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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();
}

append是同步的方法

1
CIRCLE= 2000000

DoEscapeAnalysis逃逸分析,因为这个变量能够被其他的代码块访问,就不能确定究竟是不是需要线程安全了

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

1
createStringBuffer: 187 ms
1
-server -XX:+DoEscapeAnalysis -XX:-EliminateLocks
1
createStringBuffer: 254 ms

无锁

  • 锁是悲观的操作
  • 无锁是乐观的操作
  • 无锁的一种实现方式
    CAS(Compare And Swap)
    非阻塞的同步
    CAS(V,E,N)v要更新的变量e期望值,n如果达到期望值,赋给新值
  • 在应用层面判断多线程的干扰,如果有干扰,则通知线程重试
1
java.util.concurrent.atomic.AtomicInteger
1
2
3
4
5
6
7
public final int getAndSet(int newValue) {
for (;;) {
int current = get();
if (compareAndSet(current, newValue))
return current;
}
}

设置新值,返回旧值
public final boolean compareAndSet(int expect, int update)
更新成功返回true
java.util.concurrent.atomic包使用无锁实现,性能高于一般的有锁操作

-------------The End-------------

本文标题:JVM内核-原理、诊断与优化学习笔记(九):锁

文章作者:Leesin.Dong

发布时间:2019年03月03日 - 16:03

最后更新:2019年03月03日 - 22:03

原始链接:http://mmmmmm.me/2019-03-03-2.html

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

客官客官,不可以,你要对我负责~~~