问题描述
阅读和我发现一个特定的主题非常有趣;安全出版。以下内容来自JCIP：
After reading "Java concurrent in practice" and "OSGI in practice" I found a specific subject very interesting; Safe Publication. The following is from JCIP:
- 从静态初始化程序初始化对象引用。
- 将对它的引用存储到 volatile 字段中。
- 将对它的引用存储到 final field。
- 将对它的引用存储到由（同步）锁定正确保护的字段中。
- Initializing an object reference from a static initializer.
- Storing a reference to it into a volatile field.
- Storing a reference to it into a final field.
- Storing a reference to it into a field that is properly guarded by a (synchronized) lock.
我的第一个问题：有多少java开发人员知道这个（问题）？
有多少现实世界的Java应用程序真正遵循这个，这真的是一个真正的问题吗？我有一种感觉，99％的已实现的JVM不是那种邪恶，即一个线程不能保证（事实上它实际上（几乎）不可能）看到陈旧的数据只是因为引用不遵循上面的安全发布习惯用法。
My first question: how many java developers are aware of this (problem)?How many real world java applications are really following this, AND is this really a real problem? I have a feeling that 99% of the implemented JVMs out there are not that "evil", i.e. a thread is not guaranteed (in fact its practical (almost) "impossible") to see stale data just because the reference is not following the "safe publication idiom" above.
推荐答案
按比例说，可以说很少有程序员能够充分理解同步和并发。谁知道现在有多少服务器应用程序正在管理金融交易，医疗记录，警察记录，电话等等，这些应用程序充满了同步错误，基本上是偶然的，或者偶尔会失败（从未听说过任何人得到幻像）由于原因从未真正调查或深入到底部，因此电话费被添加到电话账单中。
Proportionally, it's probably fair to say that very few programmers sufficiently understand synchronization and concurrency. Who knows how many server applications there are out there right now managing financial transactions, medical records, police records, telephony etc etc that are full of synchronization bugs and essentially work by accident, or very very occasionally fail (never heard of anybody get a phantom phone call added to their telephone bill?) for reasons that are never really looked into or gotten to the bottom of.
对象发布是一个特殊问题，因为它经常被忽视，如果您不了解它，那么编译器进行优化可能会导致意外行为是非常合理的：在JIT编译的代码中，存储指针，然后递增它并存储数据是非常合理的要做的事。您可能认为它是邪恶的，但在较低的层次上，它实际上是您对JVM规范的期望。 （顺便说一下，我听说在JRockit中运行的现实程序遇到了这个问题 - 这不是纯理论上的。）
Object publication is a particular problem because it's often overlooked, and it's a place where it's quite reasonable for compilers to make optimisations that could result in unexpected behaviour if you don't know about it: in the JIT-compiled code, storing a pointer, then incrementing it and storing the data is a very reasonable thing to do. You might think it's "evil", but at a low level, it's really how you'd expect the JVM spec to be. (Incidentally, I've heard of real-life programs running in JRockit suffering from this problem-- it's not purely theoretical.)
如果你知道你的应用程序有同步在您当前的硬件上当前的JVM中出现错误但不是行为不端，然后（a）表示祝贺; （b）现在是时候开始平静地走向火灾出口，在需要升级太多组件之前修复代码并教育程序员。
If you know that your application has synchronization bugs but isn't misbehaving in your current JVM on your current hardware, then (a) congratulations; and (b), now is the time to start "walking calmly towards the fire exit", fixing your code and educating your programmers before you need to upgrade too many components.
这篇关于Java多线程&安全出版的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！