不知道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在实现的时候并没有把性能放在首位，而是着重于概念的实现
© 2018-2020 0xFFFF
