锁对象头Mark

最新推荐文章于 2025-03-01 20:31:31 发布

江上渔者21号

最新推荐文章于 2025-03-01 20:31:31 发布

阅读量598

点赞数

分类专栏： JVM

本文链接：https://blog.youkuaiyun.com/u010325193/article/details/80786586

版权

JVM 专栏收录该内容

61 篇文章

订阅专栏

MarkWord，对象头的标记，32位

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

– 指向锁记录的指针

– 指向 monitor 的指针

– GC 标记

–偏向锁线程ID

偏向锁

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

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

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

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

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

-XX:+ UseBiasedLocking

– 默认启用

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

publicstatic List<Integer> numberList=new Vector<Integer>();

publicstatic void main(String[] args)throws InterruptedException{

long begin=System.currentTimeMillis();

intcount=0;

intstartnum=0;

while(count<10000000){

numberList.add(startnum);

startnum+=2;

count++;

}

long end=System.currentTimeMillis();

System.out.println(end-begin);

}

-XX:+UseBiasedLocking-XX:BiasedLockingStartupDelay=0

轻量级锁

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 中的

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

– 偏向锁可用会先尝试偏向锁

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

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

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

减少锁的持有时间

如果没有必要同步的，就不要放到同步快中

减小锁粒度

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

偏向锁，轻量级锁成功率提高，如果偏向锁和轻量级锁能够成功，性能提高；

ConcurrentHashMap

hashmap中维护了Entry<K,V>的数组

减少锁粒度后，可能会带来什么负面影响呢？以ConcurrentHashMap为例，说明分割为多个

Segment后，在什么情况下，会有性能损耗？

锁分离

根据功能进行锁分离

ReadWriteLock

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

	读锁	写锁
读锁	可访问	不可访问
写锁	不可访问	不可访问

例子

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

LinkedBlockingQueue

take只作用于前端，put只作用于尾端

E入队时，只要将D.last=E

A出队时，只要head=head.next

从功能的角度做分离，功能不同，互补影响，就可以分离

LinkedBlockingQueue实现中，可以使用takeLock和putLock两个锁

锁粗化

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

锁消除

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

public static void main(String args[])throws InterruptedException{

long start = System.currentTimeMillis();

for (inti= 0; i <CIRCLE; i++) {

craeteStringBuffer("JVM","Diagnosis");

}

long bufferCost= System.currentTimeMillis()- start;

System.out.println("craeteStringBuffer:" + bufferCost +" ms");

}

public static String craeteStringBuffer(Strings1, String s2) {

StringBuffersb= new StringBuffer();

sb.append(s1);

sb.append(s2);

return sb.toString();

}

未使用锁消除

无锁

锁是悲观的操作

无锁是乐观的操作

无锁的一种实现方式

– CAS(CompareAnd 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操作即时没有锁，也可以发现其他线程对当前线程的干扰，并进行恰当的处理。