标签：java multithreading concurrency operating-system scheduling

在Java Concurrency in Practice中,作者写道：

When locking is contended, the losing thread(s) must block. The JVM can implement blocking either via spin-waiting (repeatedly trying to acquire the lock until it succeeds) or by suspending the blocked thread through the operating system. Which is more efficient depends on the relationship between context switch overhead and the time until the lock becomes available; spin-waiting is preferred for short waits and suspension is preferable for long waits. Some JVMs choose between the two adaptively based on profiling data of past wait times, but most just suspend threads waiting for a lock.

当我读到这篇文章时,我感到非常惊讶.是否有任何已知的JVM通过自旋等待或有时由于分析结果而实现阻塞？现在很难相信.

解决方法:

以下证据表明JRockit可以使用自旋锁 – http://forums.oracle.com/forums/thread.jspa?threadID=816625&tstart=494

如果您在here列出的JVM选项中搜索“spin”,您将看到在Hotspot JVM中使用/支持自旋锁的证据.

标签：java,multithreading,concurrency,operating-system,scheduling
来源： https://codeday.me/bug/20190530/1187032.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。