我只是看了Java的ConcurrentHashMap的源代码,发现了这行代码:
/*
* The maximum number of times to tryLock in a prescan before possibly blocking on acquire in
* preparation for a locked segment operation. On multiprocessors, using a bounded number of
* retries maintains cache acquired while locating nodes.
*/
static final int MAX_SCAN_RETRIES =
Runtime.getRuntime().availableProcessors() > 1 ? 64 : 1
Run Code Online (Sandbox Code Playgroud)
将MAX_SCAN_RETRIES在查找条目在获取锁使用.我的问题是如何64确定多处理器机器的数量?谁知道数字背后的理论64?
在处理多个CPU的锁定重试时,在尝试快速获取锁定(旋转)和允许CPU切换到另一个线程以避免浪费CPU时间旋转到不会出现的锁定之间存在平衡.即将发布.CPU尝试获取锁定所允许的实际旋转次数受整个系统的实际速度以及通常在关键部分内执行的代码量的影响很大.
此问题深深扎根于停止问题以及与SMP系统上的OS设计相关的许多其他与优化并发性相关的问题.这种设计选择通常通过许多应用程序的试错法解决; 然而64的选择在我看来就像是实施者的任意调用(数字是2的幂).
不幸的是,这个特殊的代码既有缺陷也有限制.Buggy,因为availableProcessors的文档声明"此值可能会在特定的虚拟机调用期间发生变化",因此可能导致锁定旋转太多次(如果计数从> 1移动到= 1)或太少(在反之亦然的情况).它的局限性在于,真正需要在其应用程序中调整并发性的开发人员无法这样做,因为MAX_SCAN_RETRIES是最终的(尽管可以使用反射来播放一些技巧).
| 归档时间: |
|
| 查看次数: |
989 次 |
| 最近记录: |