Чи є хешмап Java справді O (1)?

Я бачив кілька цікавих претензій на хешмапи SO re Java та їх O(1)час пошуку. Хтось може пояснити, чому це так? Якщо ці хешмапи не сильно відрізняються від будь-якого алгоритму хешування, на який я був придбаний, завжди повинен існувати набір даних, який містить зіткнення.

У цьому випадку пошук буде O(n)швидше, ніж O(1).

Чи може хтось пояснити, чи є вони O (1), і якщо так, то як вони цього досягають?

Особливістю HashMap є те, що на відміну, скажімо, з збалансованих дерев, її поведінка є ймовірною. У цих випадках зазвичай найбільш корисно говорити про складність з точки зору ймовірності настання гіршої події. Що стосується хеш-карти, це, звичайно, є випадком зіткнення щодо того, наскільки повною є карта. Зіткнення оцінити досить просто.

p _{зіткнення} = n / потужність

Тож хеш-карта з навіть скромною кількістю елементів, швидше за все, випробує хоча б одне зіткнення. Велика нотація O дозволяє нам зробити щось більш переконливе. Зауважте, що для будь-якої довільної, фіксованої постійної k.

O (n) = O (k * n)

Ми можемо використовувати цю функцію для покращення продуктивності хеш-карти. Натомість ми могли б подумати про ймовірність максимум 2 зіткнень.

p _{зіткнення x 2} = (n / потужність) ²

Це набагато нижче. Оскільки вартість обробки одного додаткового зіткнення не має значення для продуктивності Big O, ми знайшли спосіб поліпшити продуктивність, не змінюючи алгоритм! Ми можемо зробити це загальним

p _{зіткнення xk} = (n / потужність) ^k

І тепер ми можемо знехтувати деякою кількістю довільної кількості зіткнень і закінчитися суттєво крихітною ймовірністю виникнення більшої кількості зіткнень, ніж нам належить. Ви можете отримати ймовірність до довільно крихітного рівня, вибравши правильний k, і все це не змінюючи фактичну реалізацію алгоритму.

Ми говоримо про це, кажучи, що хеш-карта має доступ до O (1) з високою ймовірністю

Ви ніби змішуєте поведінку в гіршому випадку із середнім (очікуваним) часом виконання. Перший дійсно є O (n) для хеш-таблиць загалом (тобто не використовує ідеальне хешування), але це рідко актуально на практиці.

Будь-яка реалізована хеш-таблиця в поєднанні з наполовину пристойним хешем має результати пошуку O (1) з дуже малим коефіцієнтом (насправді 2) в очікуваному випадку, в межах дуже вузької межі відхилення.

У Java HashMap працює, використовуючи hashCode, щоб знайти відро. Кожне відро - це список предметів, що містяться у цьому відрі. Елементи скануються, використовуючи для порівняння рівні. При додаванні елементів HashMap змінюється за розміром після досягнення певного відсотка навантаження.

Так, іноді доведеться порівнювати проти кількох предметів, але загалом це набагато ближче до O (1), ніж до O (n). Для практичних цілей це все, що вам потрібно знати.

Пам'ятайте, що o (1) не означає, що кожен пошук вивчає лише один елемент - це означає, що середня кількість перевірених елементів залишається незмінною wrt, кількість елементів у контейнері. Тож якщо для пошуку предмета в контейнері зі 100 предметами потрібно в середньому 4 порівняння, то також слід взяти в середньому 4 порівняння, щоб знайти предмет у контейнері з 10000 предметами та будь-яку іншу кількість елементів (завжди є трохи варіації, особливо навколо точок, в яких хеш-таблиця переробляється, і коли є дуже мала кількість елементів).

Таким чином, зіткнення не заважають контейнеру виконувати операції o (1) до тих пір, поки середня кількість ключів на відро залишається в межах фіксованої межі.

Я знаю, що це старе питання, але насправді є нова відповідь на нього.

Ви праві, що хеш-карта насправді не є O(1) , строго кажучи, тому що, оскільки кількість елементів стає довільно великою, з часом ви не зможете шукати в постійному часі (і О-нотація визначається в числах, які можуть отримати довільно великі).

Але не випливає, що складність у реальному часі є O(n) тому, що немає правила, яке говорить про те, що відра повинні бути реалізовані як лінійний список.

Насправді, Java 8 реалізує відра, як TreeMapsтільки вони перевищують поріг, що робить фактичний час O(log n).

Якщо кількість відра (називаємо це b) утримується постійним (звичайний випадок), то пошук фактично є O (n).
Коли n стає великим, кількість елементів у кожному відрі в середньому становить n / b. Якщо дозвіл на зіткнення виконується одним із звичайних способів (наприклад, пов'язаний список), то пошук - O (n / b) = O (n).

Позначення O - це те, що відбувається, коли n стає більшим і більшим. Це може ввести в оману при застосуванні до певних алгоритмів, а хеш-таблиці - це конкретний приклад. Кількість відра ми вибираємо виходячи з того, скільки елементів ми очікуємо мати справу. Коли n приблизно такого ж розміру, як b, то пошук є приблизно постійним часом, але ми не можемо його назвати O (1), оскільки О визначається через обмеження як n → ∞.

O(1+n/k) де k кількість відра.

Якщо набори реалізації , k = n/alphaто це O(1+alpha) = O(1)так alphaє постійним.

Ми встановили, що стандартний опис пошуку хеш-таблиць, що є O (1), стосується очікуваного середнього випадку, а не суворої якості в гіршому випадку. Для хеш-таблиці, що вирішує зіткнення з ланцюжком (як хешмап Java), це технічно O (1 + α) з хорошою хеш-функцією , де α - коефіцієнт навантаження таблиці. Все ще незмінно, поки кількість об'єктів, які ви зберігаєте, не більше ніж постійний коефіцієнт, більший за розмір таблиці.

Також було пояснено, що строго кажучи, можна побудувати вхід, який вимагає O ( n ) пошуку для будь-якої детермінованої хеш-функції. Але також цікаво врахувати найгірший очікуваний час, який відрізняється від середнього часу пошуку. Використовуючи ланцюжок, це O (1 + довжина найдовшої ланцюга), наприклад Θ (log n / log log n ), коли α = 1.

Якщо вас цікавлять теоретичні способи досягнення постійного очікуваного найгіршого пошуку, ви можете прочитати про динамічне ідеальне хешування, яке вирішує зіткнення рекурсивно з іншою хеш-таблицею!

Це O (1), тільки якщо ваша хеш-функція дуже хороша. Реалізація таблиці хешів Java не захищає від поганих хеш-функцій.

Чи потрібно вам розробити таблицю, коли ви додаєте елементи чи ні, це не стосується питання, оскільки йдеться про час пошуку.

Елементи всередині HashMap зберігаються у вигляді масиву пов'язаного списку (вузла), кожен пов'язаний список у масиві являє собою відро для унікального хеш-значення одного або декількох ключів.
Додаючи запис у HashMap, хеш-код ключа використовується для визначення місця розташування відра в масиві, наприклад:

location = (arraylength - 1) & keyhashcode

Тут & представляє побітовий І оператор.

Наприклад: 100 & "ABC".hashCode() = 64 (location of the bucket for the key "ABC")

Під час операції get використовує той самий спосіб визначення місця розташування відра для ключа. У кращому випадку кожен ключ має унікальний хеш-код і приводить до унікального відра для кожного ключа, у цьому випадку метод get витрачає час лише на визначення місця розташування та отримання значення, яке є постійним O (1).

У найгіршому випадку всі ключі мають однаковий хеш-код і зберігаються в одному відрі, це призводить до проходження всього списку, що призводить до O (n).

У випадку з java 8 відро зв'язаного списку замінюється на TreeMap, якщо розмір збільшується до більш ніж 8, це знижує найгірший випадок ефективності пошуку до O (log n).

Це в основному стосується більшості реалізацій хеш-таблиць у більшості мов програмування, оскільки сам алгоритм насправді не змінюється.

Якщо в таблиці немає зіткнень, вам потрібно зробити лише один огляд, тому час роботи - O (1). Якщо є зіткнення, вам доведеться виконати більше одного огляду, який призводить до зниження продуктивності у напрямку до O (n).

Це залежить від алгоритму, який ви вибрали, щоб уникнути зіткнень. Якщо ваша реалізація використовує окремий ланцюжок, тоді найгірший сценарій трапляється, коли кожен елемент даних хешируется з однаковим значенням (наприклад, поганий вибір хеш-функції). У цьому випадку пошук даних не відрізняється від лінійного пошуку у зв'язаному списку, тобто O (n). Однак ймовірність того, що станеться, незначна, і найкращі випадки пошуку і середні випадки залишаються постійними, тобто O (1).

З точки зору вчених, з практичної точки зору, HashMaps слід сприймати як такий, що має несуттєвий вплив на продуктивність (якщо тільки ваш профілер не скаже вам про інше).

Тільки в теоретичному випадку, коли хеш-коди завжди різні, а відро для кожного хеш-коду також різне, O (1) буде існувати. В іншому випадку він є постійним порядком, тобто при збільшенні хешмапу, його порядок пошуку залишається постійним.

Звичайно, продуктивність хешмапу буде залежати від якості функції хеш-коду () для даного об'єкта. Однак якщо функція реалізована таким чином, що можливість зіткнень дуже низька, вона матиме дуже гарну продуктивність (це не є строго O (1) у кожному можливому випадку, але це в більшості випадків).

Наприклад, реалізація за замовчуванням в Oracle JRE полягає у використанні випадкового числа (яке зберігається в екземплярі об'єкта, щоб воно не змінювалося, але воно також вимикає упереджене блокування, але це інша дискусія), тому шанс зіткнень дуже низький.