深入 JVM 内核—原理、诊断与优化之: 锁 (九)
线程安全
-
多线程网站统计访问人数
- 使用锁,维护计数器的串行访问与安全性
-
多线程访问ArrayList
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++;
}
}
}
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());
}
在ArrayList进行扩容的时候处于不可用状态,这时进行操作会发生IndexOutOfBoundException
对象头Mark
-
Mark Word,对象头的标记,32位
-
描述对象的hash、锁信息,垃圾回收标记,年龄
-
指向锁记录的指针
-
指向monitor的指针
-
GC标记
-
偏向锁线程ID
-
偏向锁
-
大部分情况是没有竞争的,所以可以通过偏向来提高性能
-
所谓的偏向,就是偏心,即锁会偏向于当前已经占有锁的线程
-
将对象头Mark的标记设置为偏向,并将线程ID写入对象头Mark
-
只要没有竞争,获得偏向锁的线程,在将来进入同步块,不需要做同步
-
当其他线程请求相同的锁时,偏向模式结束
-
-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);
}
本例中,使用偏向锁,可以获得5%以上的性能提升
-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
-XX:-UseBiasedLocking
轻量级锁
-
BasicObjectLock
- 嵌入在线程栈中的对象
-
普通的锁处理性能不够理想,轻量级锁是一种快速的锁定方法。
-
如果对象没有被锁定
-
将对象头的Mark指针保存到锁对象中
-
将对象头设置为指向锁的指针(在线程栈空间中)
-
lock->set_displaced_header(mark);
if (mark == (markOop) Atomic::cmpxchg_ptr(lock, obj()->mark_addr(), mark)) {
TEVENT (slow_enter: release stacklock) ;
return ;
}
lock位于线程栈中,判断一个线程是否持有轻量级锁,只要判断对象头的指针,是否在线程的栈空间范围内
-
如果轻量级锁失败,表示存在竞争,升级为重量级锁(常规锁)
-
在没有锁竞争的前提下,减少传统锁使用OS互斥量产生的性能损耗
-
在竞争激烈时,轻量级锁会多做很多额外操作,导致性能下降
自旋锁
-
当竞争存在时,如果线程可以很快获得锁,那么可以不在OS层挂起线程,让线程做几个空操作(自旋)
-
JDK1.6中-XX:+UseSpinning开启
-
JDK1.7中,去掉此参数,改为内置实现
-
如果同步块很长,自旋失败,会降低系统性能
-
如果同步块很短,自旋成功,节省线程挂起切换时间,提升系统性能
偏向锁,轻量级锁,自旋锁总结
-
不是Java语言层面的锁优化方法
-
内置于JVM中的获取锁的优化方法和获取锁的步骤
-
偏向锁可用会先尝试偏向锁
-
轻量级锁可用会先尝试轻量级锁
-
以上都失败,尝试自旋锁
-
再失败,尝试普通锁,使用OS互斥量在操作系统层挂起
-
减少锁持有时间
public synchronized void syncMethod(){
othercode1();
mutextMethod();
othercode2();
}
public void syncMethod2(){
othercode1();
synchronized(this){
mutextMethod();
}
othercode2();
}
持有时间长,自旋容易失败
减小锁粒度
-
将大对象,拆成小对象,大大增加并行度,降低锁竞争
-
偏向锁,轻量级锁成功率提高
-
ConcurrentHashMap
-
HashMap的同步实现
-
Collections.synchronizedMap(Map<K,V> m)
-
返回SynchronizedMap对象
-
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
-
读多写少的情况,可以提高性能
-
读写分离思想可以延伸,只要操作互不影响,锁就可以分离
-
LinkedBlockingQueue
-
队列
-
链表
-
take只作用于前端,put只作用于尾端,E入队时,只要将D.last=E,A出队时,只要head=head.next,从功能的角度做分离,功能不同,互补影响,就可以分,LinkedBlockingQueue实现中,可以使用takeLock和putLock两个锁
锁粗化
通常情况下,为了保证多线程间的有效并发,会要求每个线程持有锁的时间尽量短,即在使用完公共资源后,应该立即释放锁。只有这样,等待在这个锁上的其他线程才能尽早的获得资源执行任务。但是,凡事都有一个度,如果对同一个锁不停的进行请求、同步和释放,其本身也会消耗系统宝贵的资源,反而不利于性能的优化
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){
}
}
synchronized(lock){
for(int i=0;i<CIRCLE;i++){
}
}
锁消除
在即时编译器时,如果发现不可能被共享的对象,则可以消除这些对象的锁操作
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();
}
锁不是由程序员引入的,JDK自带的一些库,可能内置锁,栈上对象,不会被全局访问的,没有必要加锁
CIRCLE= 2000000
-server -XX:+DoEscapeAnalysis -XX:+EliminateLocks
createStringBuffer: 187 ms
-server -XX:+DoEscapeAnalysis -XX:-EliminateLocks
createStringBuffer: 254 ms
无锁
-
锁是悲观的操作
-
无锁是乐观的操作
-
无锁的一种实现方式
-
CAS(Compare And Swap)
-
非阻塞的同步
-
CAS(V,E,N)
-
-
在应用层面判断多线程的干扰,如果有干扰,则通知线程重试
CAS算法的过程是这样:它包含3个参数CAS(V,E,N)。V表示要更新的变量,E表示预期值,N表示新值。仅当V值等于E值时,才会将V的值设为N,如果V值和E值不同,则说明已经有其他线程做了更新,则当前线程什么都不做。最后,CAS返回当前V的真实值。CAS操作是抱着乐观的态度进行的,它总是认为自己可以成功完成操作。当多个线程同时使用CAS操作一个变量时,只有一个会胜出,并成功更新,其余均会失败。失败的线程不会被挂起,仅是被告知失败,并且允许再次尝试,当然也允许失败的线程放弃操作。基于这样的原理,CAS操作即时没有锁,也可以发现其他线程对当前线程的干扰,并进行恰当的处理。
- java.util.concurrent.atomic.AtomicInteger
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包使用无锁实现,性能高于一般的有锁操作