Чи безпечно отримувати значення з java.util.HashMap з декількох потоків (без змін)?

Існує випадок, коли карта буде побудована, і як тільки вона буде ініціалізована, вона більше ніколи не буде змінена. Однак доступ до нього (лише через get (key)) можна отримати з декількох потоків. Чи безпечно використовувати java.util.HashMapтакий спосіб?

(В даний час я із задоволенням використовую програму java.util.concurrent.ConcurrentHashMapта не маю міри необхідності в підвищенні продуктивності, але мені просто цікаво, чи HashMapвистачить простого . Отже, це питання не "Кого я повинен використовувати?", А також не питання про продуктивність. Швидше питання "Чи було б це безпечно?")

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

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

Наприклад, уявіть, що ви публікуєте карту так:

class SomeClass {
   public static HashMap<Object, Object> MAP;

   public synchronized static setMap(HashMap<Object, Object> m) {
     MAP = m;
   }
}

... і в якийсь момент setMap()викликається картою, а інші потоки використовують SomeClass.MAPдля доступу до карти, і перевіряють наявність нуля, як це:

HashMap<Object,Object> map = SomeClass.MAP;
if (map != null) {
  .. use the map
} else {
  .. some default behavior
}

Це не є безпечним, хоча це, мабуть, здається, що воно є. Проблема полягає в тому, що між набором та наступним зчитуванням на іншій нитці не відбувається жодного зв'язку SomeObject.MAP, тому порядок читання вільний бачити частково побудовану карту. Це в значній мірі може зробити все, що завгодно, і навіть на практиці це робить такі речі, як покласти нитку для читання в нескінченну петлю .

Щоб безпечно опублікувати карту, вам необхідно встановити відбувається, перш за , ніж відносини між написанням посилання на HashMap(тобто, публікацію ) та наступних читачами цієї посилання (тобто споживання). Зручно, що існує лише кілька легких для запам'ятовування способів досягти цього ^[1] :

1. Обмінятись посиланням через правильно заблоковане поле ( JLS 17.4.5 )
2. Використовуйте статичний ініціалізатор, щоб зробити ініціалізаційні сховища ( JLS 12.4 )
3. Обміняти посилання за допомогою летючого поля ( JLS 17.4.5 ) або, як наслідок цього правила, через класи AtomicX
4. Ініціалізуйте значення в остаточному полі ( JLS 17.5 ).

Найцікавіші для вашого сценарію (2), (3) та (4). Зокрема, (3) стосується прямо вказаного вище коду: якщо ви перетворите декларацію MAPна:

public static volatile HashMap<Object, Object> MAP;

то все кашрута: читачі , які бачать нульове значення обов'язково є відбувається, перш за , ніж відносини з магазином до MAPі , отже , побачити всі магазини , пов'язані з ініціалізацією карти.

Інші методи змінюють семантику вашого методу, оскільки обидва (2) (за допомогою статичного ініталізатора) та (4) (за допомогою кінцевого ) означають, що ви не можете MAPдинамічно встановлювати час виконання. Якщо вам цього не потрібно , просто задекларуйте це MAPяк static final HashMap<>і вам гарантовано безпечне опублікування.

На практиці правила прості для безпечного доступу до "ніколи не змінених об'єктів":

Якщо ви публікуєте об'єкт, який за своєю суттю не є незмінним (як у всіх заявлених полях final), і:

• Ви вже можете створити об’єкт, який буде призначений на момент оголошення ^a : просто використовуйте finalполе (у тому числі static finalдля статичних членів).
• Ви хочете призначити об'єкт пізніше, після того як посилання вже буде видно: використовуйте летюче поле ^b .

Це воно!

На практиці це дуже ефективно. Використання static finalполя, наприклад, дозволяє JVM припустити, що значення є незмінним протягом життя програми та сильно оптимізувати його. Використання finalполя-члена дозволяє більшості архітектур зчитувати поле таким чином, що еквівалентно звичайному зчитуваному полю, і не гальмує подальші оптимізації ^c .

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

Більш детальні відомості див. У Шипілєві або в цьому поширеному питанні від Менсона та Геца .

[1] Безпосередньо цитуючи з shipilev .

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

^b Необов'язково, ви можете використовувати synchronizedметод для отримання / встановлення, AtomicReferenceабо щось або щось, але ми говоримо про мінімальну роботу, яку ви можете виконати.

c Деякі архітектури з дуже слабкими моделями пам'яті (я дивлюся на вас , Альфа), можливо, потребують певного бар'єру читання перед finalпрочитаним - але це сьогодні дуже рідко.

Джеремі Менсон, бог, що стосується Моделі пам’яті Java, має цю частину блогу на цю тему - адже, по суті, ви задаєте питання «Чи безпечно отримати доступ до незмінного HashMap» - відповідь на це так. Але ви повинні відповісти на присудок на те питання, яке є - "Чи мій HashMap незмінний". Відповідь може вас здивувати - у Java є відносно складний набір правил для визначення незмінності.

Щоб отримати докладнішу інформацію про тему, читайте публікації в блозі Джеремі:

Частина 1 про незмінність на Java: http://jeremymanson.blogspot.com/2008/04/immutability-in-java.html

Частина 2 про незмінність на Java: http://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-2.html

Частина 3 про незмінність на Java: http://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-3.html

Показання є безпечними з точки зору синхронізації, але не з точки зору пам'яті. Це те, що широко не зрозуміло серед розробників Java, включаючи тут, на Stackoverflow. (Дотримуйтесь оцінки цієї відповіді для підтвердження.)

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

Детальніше дивіться у статті Брайана Геца про нову модель пам'яті Java .

Трохи роздивившись, я виявив це в документі java doc (акцент мій):

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

Це, мабуть, означає, що це буде безпечно, якщо припустити, що зворотне твердження є правдивим.

Одне зауваження полягає в тому, що за деяких обставин отримання () від несинхронізованого HashMap може спричинити нескінченний цикл. Це може статися, якщо паралельний put () спричинить повторний перегляд карти.

http://lightbody.net/blog/2005/07/hashmapget_can_ why_an_infini.html

Однак є важливий поворот. Доступ до карти безпечно, але в цілому не гарантується, що всі потоки побачать точно той самий стан (і, таким чином, значення) HashMap. Це може статися в багатопроцесорних системах, де модифікації HashMap, здійснені одним потоком (наприклад, той, який його заселив), можуть сидіти в кеш-пам'яті цього процесора і не будуть помічені потоками, що працюють на інших процесорах, поки операція забору пам’яті не буде виконується забезпечення узгодженості кешу. Специфікація мови Java є чіткою для цього: рішення полягає у придбанні блокування (синхронізованого (...)), яке випромінює операцію забору пам'яті. Отже, якщо ви впевнені, що після заповнення HashMap кожен з потоків отримує БУДЬ-який замок, то з цього моменту буде нормально отримати доступ до HashMap з будь-якого потоку, поки HashMap знову не буде змінено.

Відповідно до http://www.ibm.com/developerworks/java/library/j-jtp03304/ # Безпека ініціалізації ви можете зробити ваш HashMap остаточним полем і після закінчення конструктора воно буде безпечно опубліковано.

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

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

Для прикладу того, як погано карти можуть вийти з ладу при одночасному використанні, і запропонований нами спосіб вирішення, ознайомтеся з цією записом параду помилок: bug_id = 6423457

Це питання вирішено в книзі Брайана Геца "Конкурс Java в практиці" (Лістинг 16.8, стор. 350):

@ThreadSafe
public class SafeStates {
    private final Map<String, String> states;

    public SafeStates() {
        states = new HashMap<String, String>();
        states.put("alaska", "AK");
        states.put("alabama", "AL");
        ...
        states.put("wyoming", "WY");
    }

    public String getAbbreviation(String s) {
        return states.get(s);
    }
}

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

Попереджуйте, що навіть у однопотоковому коді заміна ConcurrentHashMap на HashMap може не бути безпечною. ConcurrentHashMap забороняє нуль як ключ або значення. HashMap не забороняє їх (не питайте).

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

Однак, за умови, що ви нічого не робите, паралельні читання з HashMap є безпечними.

[Редагувати: під "одночасними читаннями", я маю на увазі, що не існує також одночасних модифікацій.

Інші відповіді пояснюють, як це забезпечити. Один із способів - зробити карту непорушною, але це не обов'язково. Наприклад, модель пам'яті JSR133 чітко визначає, що започаткування потоку має бути синхронізованою дією, тобто зміни, внесені в потік А перед початком потоку B, видно в потоці B.

Моя мета - не суперечити тим більш детальним відповідям щодо моделі пам'яті Java. Ця відповідь призначена для того, щоб вказати, що навіть окрім проблем із паралельністю, між ConcurrentHashMap та HashMap існує, щонайменше, одна різниця API, яка могла б скапувати навіть однопоточну програму, яка замінила одну на іншу.]

http://www.docjar.com/html/api/java/util/HashMap.java.html

ось джерело для HashMap. Як ви можете сказати, в ньому абсолютно немає коду блокування / mutex.

Це означає, що хоча добре читати з HashMap у багатопотоковій ситуації, я б неодмінно використовував ConcurrentHashMap, якщо було кілька записів.

Що цікаво, це те, що і .NET HashTable, і словник <K, V> вбудували код синхронізації.

Якщо ініціалізація та кожне введення синхронізовано, ви економите.

Наступний код зберігається, оскільки завантажувач класів подбає про синхронізацію:

public static final HashMap<String, String> map = new HashMap<>();
static {
  map.put("A","A");

}

Наступний код є збереженням, тому що написання летких речовин буде піклуватися про синхронізацію.

class Foo {
  volatile HashMap<String, String> map;
  public void init() {
    final HashMap<String, String> tmp = new HashMap<>();
    tmp.put("A","A");
    // writing to volatile has to be after the modification of the map
    this.map = tmp;
  }
}

Це також буде працювати, якщо змінна-член остаточна, оскільки остаточна також мінлива. І якщо метод - конструктор.