不知道AQS 的阻塞队列是否是属于Java层面的实现,而重量级锁则是操作系统实现?
synchronized 是关键字 , 是 Java 亲儿子 , class 文件里面甚至为 synchronized 留有单独的标识 , 对象头里面关于锁的信息就是给 synchronized 优化用的 , 而 AQS 只是一个关于锁的一个工具罢了 , 你也可以把它的代码复制一份叫 xiao AQS , 照样用(doge
说回来 , synchronized 确实是基于操作系统 , JIT后的汇编码有 lock comxchg 之类的指令
谢谢!困惑少多了,这里的汇编码现在是comxchg 是说明目前是采用的是轻量级锁对吧?
xiao 应该是吧 , 所以有亲爸爸优化后的 synchronized , 性能也还好
请问AQS是如何实现阻塞的,难道不需要借助操作系统实现线程的阻塞和唤醒吗?如果需要那感觉倒和synchronized早期版本一样了
貌似底层就是借助了操作系统,AQS是基于LockSupport这个有native方法的类实现线程阻塞与唤醒。 另,Doug Lea早年实现AQS的时候是写了篇论文的,看看也许对研究AQS有所帮助#LearnFromTheAuthor
谢谢!刚看了论文,这里用的是park来阻塞线程,如果park底层也是操作系统层级的,那这里感觉aqs和synchronized的主要区别就在于:aqs是自己在java层面实现的阻塞队列,而synchronized是借助操作系统实现的阻塞队列,不知道可否这样理解
也可以,synchronize是JVM级别的锁原语,如果是重量级锁状态的话是基于操作系统的锁实现的,锁的等待队列由操作系统管理。AQS应该把等待队列拉出来自己做,只是借用了操作系统的API阻塞和解除阻塞线程来暂停执行,等待锁可用而已。
我又来了,感觉还是不太理解,lock和早期的synchronized都需要对线程进行唤醒和阻塞,那为什么lock比synchronized快呢?好像都需要经历内核态和用户态的切换呀?
https://concurrency-interest.altair.cs.oswego.narkive.com/Bx94AChl/why-is-reentrantlock-faster-than-synchronized 谷歌了一下,这里有一个链接,doug lea曾经亲自回答了这个问题,事实上aqs更快的原因还是在于,aqs在实现的时候相比于synchronized做了很多的优化,而且本身设计Lock的初衷也是在于提供更高的灵活性,在此基础上对性能做了优化
xiao 早期synchronized在实现的时候并没有把性能放在首位,而是着重于概念的实现
最近在看 HotSpot,有了更深刻的理解
AQS 和 synchronized 都是用的 park (这里只讨论 posix 实现)
LockSupport.park()
JavaThread->parker()->park()
os::PlatformEvent
Thread->_ParkEvent->park()
os::PlatfomEvent
在上面的前提下,去看它俩的区别
os::PlatformEvent::park()
pthread_cond_wait()
© 2018-2023 0xFFFF