两年后，我的一个测试（测试一些并发db-transaction-stuff）突然开始在构建服务器上使用BrokenBarrierException失败。它曾经一直在工作，现在它失败了三个版本中的一个。它永远不会在Windows工作站上失败。
谁有线索为什么？构建服务器使用此操作系统： Linux版本2.6.5-7.244-bigsmp（geeko @ buildhost）（gcc版本3.3.3（SuSE Linux））＃1 SMP周一12月12日18:32:25 UTC 2005 在一对氙气芯片上
和这个java版本： java版“1.6.0_16” Java（TM）SE运行时环境（版本1.6.0_16-b01） Java HotSpot（TM）服务器VM（版本14.2-b01，混合模式）
答案 0 :(得分：1)
我会猜测失败是真的。
许多技术上不正确的并发代码的问题在于它将适用于大量的工具。典型的例子是当它们需要可见性时，将字段声明为volatile，这通常适用于单核机器，然后在多核机器上失败。但是，可能会出现更多微妙的错误，依赖于诸如JLS允许允许的潜在重新排序之类的东西，但可能没有在任何当前的JVM实现中实现。
有可能是硬件/软件升级应该是微不足道的，但现在正在解决这个并发问题。或者，日期的变化很可能影响问题的可见性（如果在测试中使用new Date()之类的任何东西，理论上不同的值可能导致优化使用稍微不同的路径）。或者这甚至可以归结为其他一些过去常常在盒子上停止运行的过程;当有更多的备用周期时，HotSpot完全有可能查看CPU利用率并执行更积极的优化（事实上， / em>的）。
基本上，如果您遇到的并发问题只是通过一些微妙的重新排序或优化而暴露出来，这可能会也可能不会发生，具体取决于JVM编译器的实现细节。因此，安装新的JVM可能会触发这一点，但同样可以通过任何引发，导致编译器的行为略有不同。