Java集合 modCount为什么不用volatile修饰?

发布于 2022-09-11 19:54:52 字数 230 浏览 14 评论 0

2个线程 访问一个list 其中一个remove操作了 另一个在迭代 假如不用vol修饰 那么在迭代的那个线程可能感知不到modcount的变化啊
甚至于说官方认为有volatile是一个BUG?https://bugs.java.com/bugdata...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

林空鹿饮溪 2022-09-18 19:54:52

我觉得你是理解有误,首先Java集合中有modCount属性未加volatile的都是线程不安全的集合类,都是单线程集合类single thread collections,讲单线程集合类放到多线程中去讨论,是很不合适的。

所以你的假设,在多线程情况下的可见行问题,根本就不应该出现这个问题!因为你的思路就有问题。

要保证有这个属性的集合类的正确使用至少不会出现在多线程的编程中这是前提条件,为什么呢?
fail-fast机制是确保集合类遍历过程中集合类不会出现结构性修改(增、删元素)
一般认为在遍历时出现结构性修改那么遍历将无法保证所有元素均能被遍历到(新增时)也无法顺利完成遍历(删除时)
要在遍历是进行结构性修改必须配合Iterator提供的remove()方法

我觉得你应该考虑的问题是为什么会出现fail-fast机制这个东西,这个东西的出现是为了解决什么样子的问题。

你要记住modCount本身就不是为多线程准备的,再多线程情况下诸如ArrayList之类的集合类连本身线程安全都保证不了,又有什么必要去设计一个线程安全的modCount呢?

你要一个先天就不具备线程安全的类去实现线程安全的问题干嘛呢,这根本不是它考虑的问题,这完全没有必要。如果真这么做了,就不仅仅是设计过度的问题了。

叫思念不要吵 2022-09-18 19:54:52
Since the modCount mechanism comes with no guarantees, and users of
single-threaded collections do not expect to pay the (high) price
of a volatile write on every modification operation, the volatile
modifier should be removed.

Description里都写的那么清楚了 还有什么可问的?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文