Почему HashTable все еще существует в Java, когда ConcurrentHashMap более эффективен, чем он?

Насколько мне известно, ConcurrentHashMap разделяет сегменты и имеет отдельные блокировки для каждого раздела. Но HashTable имеет одну единственную блокировку для всех сегментов.

В результате ConcurrentHashMap может быть либо более эффективным, либо (в худшем случае) таким же эффективным, как HashTable. Итак, почему Java должен поддерживать HashTable в своих последних версиях.

Разве HashTable не устарела? Или все же есть какие-то преимущества HashTable перед ConcurrentHashMap?


java hashmap concurrency hashtable concurrenthashmap
person pranjal thakur    schedule 04.11.2016    source источник
comment
Так почему же Java должен поддерживать HashTable в своих последних версиях для обратной совместимости?   -  person a_horse_with_no_name    schedule 04.11.2016

Ответы (2)


arrow_upward
5
arrow_downward

По очень простой причине: эта классика может содержать миллионы строк кода. И люди, которые хотели бы перекомпилировать этот код, используя более новый JDK.

Вы хотите сломать их всех!?

person GhostCat    schedule 04.11.2016
comment
С другой стороны, Oracle уже много раз ломала апплеты, меняя базовый уровень безопасности, требующий новых записей в манифесте. Клиенты обновляют свои JRE, и вам звонят посреди ночи. - person KC Wong; 04.11.2016
comment
Тот факт, что Sun/Oracle принимают одно решение в один день, не означает, что они не будут принимать другие решения в другие дни ;-) - person GhostCat; 04.11.2016
comment
Кроме того, Properties extends Hashtable. Так что на самом деле мы весело используем его везде. - person Marko Topolnik; 04.11.2016
comment
Конечно, теоретически можно было бы даже подумать о сохранении интерфейса Hashtable, но полностью переработать его внутреннюю реализацию; но это может вызвать странные эффекты здесь или там; а значит: тоже не очень хорошая идея! - person GhostCat; 04.11.2016
comment
Вы не можете переделать внутренности Hashtable, чтобы они были похожи на ConcurrentHashMap. Важной частью его дизайна является то, что он действительно использует synchronized, а это означает, что клиентский код также может использовать synchronized для выполнения многоэтапного обновления с гарантией блокировки всех других одновременных доступов. Такой код вообще нельзя перенаправить на использование ConcurrentHashMap; тогда потребуется совершенно другой алгоритм. Мы даже не можем предположить, что у каждого варианта использования есть альтернатива без блокировки. - person Holger; 25.01.2021

arrow_upward
1
arrow_downward

Эта концепция применима НЕ только к Hashtable, фактически она применима ко всем устаревшим классам, поскольку ожидается, что версии Java будут обратно совместимы в двоичном формате.

Это будет очень полезно для приложений или проектов, которые хотят перейти на более новые версии Java, не беспокоясь об изменении существующих функций, которые используют некоторые устаревшие классы (такие как Hashtable, Vector и т. д.).

Обратная совместимость

Ожидается, что версии Java будут двоично обратно совместимыми. Например, JDK 8 может запускать код, скомпилированный JDK 7 или JDK 6. Обычно приложения используют эту обратную совместимость, используя компоненты, созданные другой версией Java. Руководство по совместимости (поясняется позже) существует для каждого основного выпуска, чтобы особо отметить, что что-то несовместимо с предыдущими версиями.

Вы можете посмотреть здесь

person developer    schedule 04.11.2016