为什么HashTable在Java中仍然存在，而ConcurrentHashMap比它更有效？

据我所知，ConcurrentHashMap对bucket进行分区，并且在每个分区上都有独立的锁。但是哈希表对所有存储桶都有一个单锁

因此，ConcurrentHashMap要么效率更高，要么（在最坏的情况下）与HashTable一样高效。那么为什么Java需要在其最新版本中保留哈希表呢

---

哈希表现在不是被禁用了吗？或者HashTable还有一些优于ConcurrentHashMap的优点吗？

一个非常简单的原因：可能有无数行代码使用这个经典。以及希望使用较新的JDK重新编译代码的人

---

你想把它们都打破

这个概念不仅适用于

哈希表

，事实上它也适用于所有遗留类，因为Java版本应该是二进制向后兼容的

这对于希望升级到Java新版本的应用程序或项目非常有帮助，而不必担心修改其现有功能，这些功能使用了一些遗留类（如

哈希表

，

向量

，等等）

向后兼容性

Java版本应该是二进制向后兼容的。对于 例如，JDK8可以运行由JDK7或JDK6编译的代码。这很常见 要查看应用程序，请使用 由不同Java版本构建的组件。兼容性指南 （稍后解释）存在于每个主要版本中，以提供特殊的 当某些内容不向后兼容时提及

---

您可以查看

“那么为什么Java需要在其最新版本中保留哈希表”，因为向后兼容。另一方面，Oracle以前多次破坏小程序，因为它移动了需要在清单中添加新条目的安全基线。客户更新他们的JRE并在半夜接到电话。Sun/Oracle有一天做出一个决定并不意味着他们不会在其他日子做出其他决定；另外，

属性扩展了Hashtable

。因此，实际上我们到处都在愉快地使用它。当然，理论上，人们甚至可以考虑保留哈希表接口，但完全修改其内部实现；但这可能会在这里或那里造成奇怪的影响；因此：这也不是一个好主意！您不能将

Hashtable

的内部修改为类似于

ConcurrentHashMap

。它的设计的一个关键部分是使用了

synchronized

，这意味着客户端代码也可以使用

synchronized

，在保证所有其他并发访问被阻止的情况下执行多步骤更新。这样的代码根本无法重定向到使用

ConcurrentHashMap

；这将需要一个完全不同的算法。我们甚至不能假设每个用例都有一个无锁的替代方案。