В большое количество потоков передается ссылка на объект HashMap. Эти потоки только добавляют в HashMap значения. Вопрос, надо ли делать HashMap синхронизированным?

Нужно, лучше использовать ConcurrectHashMap

Чем канкарент хеш мап не угодил?

Просто я не со всем глубоко понимаю зачем мне канкарент? Я же только вставляю запись в мапу. Зачем мне блокировать? У меня разве могут записаться значения в один и тот же бакет?

могут

Канкарент не блочит

а почему они могут записать в один и тот же бакет? hash код же уникален?

Хэш код не уникален. Колизии же возможны.

Ну да это понятно, но как у меня может встретится одинаковый хэшкод если ключ и значения даже все уникальные

По этому всё равно не понятно, зачем мне канкарент в hashmap при только вставке. При редактировании понятно дело что нужен

Хеш ограничен интом => не уникален

/stat@combot

combot.org/chat/-1001043090457

это получается что при вставке к hashmap в одном даже потоке, может записаться в один и тот же бакет?

это получается что при вставке к hashmap в одном даже потоке, может записаться в один и тот же бакет?

да, эта ситуация вполне штатная и для нее есть встроенное решение

а где посмотреть или как называется?

уже нашёл

любо совпал хэшкод (произошла коллизия), тогда элементом этого массива устанавливается новая запись, у которой есть поле, ссылающееся на старую запись. Таким образом, в следующий раз для просмотра записей в этом элементе необходимо будет пройти связанный список записей <ключ, значение>.

но всё равно зачем тогда канкарент?)) для Array листа тоже понятно зачем нужен канкарент для вставки. Ну а для Hash зачем нужен если идёт вставка не по номеру, а по хэшкоду

У тебя в 2х потоках происходит коллизия, первый поток создает связанный элемент. Второй создает его же и перезатирает значение которое внес первый

а теперь понятно) спасибо)

Ну и хешмэп может делать resize. Когда другой поток захочет добавить запись

Не будет коллизии из двух потоков

как генерится hashcode в java 1.8, недавно на хабре была статься про это

что используется алгоритм. Состояние потока + xorshift

А состояние потока это

входят такие параметры, как стек, набор значений регистров процессора, адрес исполняемой команды и прочее

Так 2 разных потока не могут сделать одинаковый хэшкод

по этому канкарент в hash map мне точно не нужен

может все таки в этой статье говорилось про identity hashcode?

hashcode по умолчанию

https://habrahabr.ru/company/mailru/blog/321306/

в заголовке об этом и написано

и для hashmap это не относится?

точнее генерация hashcode в нём

посмотри код добавления элемента в hashmap

hashcode это один из методов класса object

в мапе вычисляется хэш на основе хэшкода переданного объекта

чёт читаю не могу понять в чём разница от по умолчанию и от object

То чувство, когда в learnjava темы хардкорнее

угу, с утра там константпул человек писать пытался

Тот что по умолчанию как бы определен в object классе, от которого наследует ся все и вся

чёт читаю не могу понять в чём разница от по умолчанию и от object

Если никто не перебил этот метод в иерархии, значит будет хэшкод по умолчанию

Но если его никто не переопределил, значит тебе, как пользователю, он скорее всего не понадобится

-Если никто не перебил -Но если его никто не переопределил ???

Зачем тебе вообще мапа у которой в качестве ключей объекты у которых identity hash code?

Я всё равно не понял в чем отличия от по умолчанию и от object. У меня в мапе ключ это String. Все уникальные ключи. HashCode так и сяк будет разный всегда и не должно быть коллизии при вставке с нескольких потоках

Посмотри для начала какой контакт должен быть у equals и hashcode, посмотри как добавляются элементы в hashmap, что происходит когда у элементов одинаковый hashcode

Я всё равно не понял в чем отличия от по умолчанию и от object. У меня в мапе ключ это String. Все уникальные ключи. HashCode так и сяк будет разный всегда и не должно быть коллизии при вставке с нескольких потоках

У String не дефолтная реализация hashcode, статья на хабре для твоего случая не актуальна. Коллизии возможны, и ресайз возможен, поэтому на запись даже с разными ключами HashMap не потокобезопасен.

У String не дефолтная реализация hashcode, статья на хабре для твоего случая не актуальна. Коллизии возможны, и ресайз возможен, поэтому на запись даже с разными ключами HashMap не потокобезопасен.

теперь встало всё наполочки) спасибо

запись не запись, ты когда из нее читать потом будешь можно значения пропустить изза того что синхронизации нет

Чтение уже идёт когда все потоки отработали

и что

у тебя нет гарантии что эти потоки свои изменения скинули в общую память

тот поток который читает может сидеть со своей закешированной мапой и ничего не знать про то что в нее записывали

понял

но с 10к записями коллизии ещё не возикало. По этому этот вариант и не думал

но с 10к записями коллизии ещё не возикало. По этому этот вариант и не думал

как тебе уже выше сказали, hashcode - ограничен интом. попробуй добавь в мапу [размер_инта]+1 и подумай, какой хешкод должен иметь этот элемент

По этому всё равно не понятно, зачем мне канкарент в hashmap при только вставке. При редактировании понятно дело что нужен

Реализация хэшмапа может использовать внутри массивы (или тот же ArrayList) для хранения объектов с совпавшими хэшами, или ещё как-нибудь хитро поступать. В итоге у тебя любая модификация мапы может привести к расширению этих ArrayList ов. Ну а почему добавление элемента в ArrayList нужно делать с блокировками — ты, судя по твоим словам, уже понимаешь. Пока ты полностью не проверифицировал *весь* код используемой тобой реализации HashMap, ты *ничего* не можешь сказать про то, имеешь ли ты право опустить там блокировки. Моя ставка, что не имеешь. В конце концов, документация в явном виде говорит, что при "структурных модификациях" ты обязан блокировать работу с HashMap (и приводит определение структурных модификаций — это удаления и добавления). Всё остальное, о чём не говорит документация — слухи и догадки, и может поменяться даже в минорных апдейтах. Документация тут: https://docs.oracle.com/javase/8/docs/api/java/util/HashMap.html см. со слов "Note that this implementation is not synchronized"

тут вот классный ответ по этой теме есть http://stackoverflow.com/a/2688817/431270

провайдер дал sdk для интеграции с его системой. этот sdk немного подтекает. даже если на каждый запрос создаешь с нуля клиента из-за того что он внутри сам себе создает потоки, делает гадость со статикой, он все равно кушает память что делать в такой ситуации?

на SO говорят делать форк процесса с jvm и там делать "грязную работу", через N итераций сносить этот процесс и поднимать новый

ERROR: S client not available

дело говорят :)

System.exit(1) :) Как-товидел такое в одном проекте. Перезапускали так веб сервер чтобы память не утекала )

System.exit(1) :) Как-товидел такое в одном проекте. Перезапускали так веб сервер чтобы память не утекала )

я сразу подумал что это в пхп руме мне написали)

вот ) а я это видел в джава проекте )

System.exit(1) :) Как-товидел такое в одном проекте. Перезапускали так веб сервер чтобы память не утекала )

А а чем проблема с System.exit(1)? И в чем проблема с очисткой памяти перезапуском?

В том, что это плохо? Хотябы тем же SLA

В том, что это плохо? Хотябы тем же SLA

Ну это смотря как сделано. На пример убивающихся нод несколько, а перед ними стоит балпнсироващик.

Когда старт приложения 5 секунд и всего 1 инстанс запущен, то не очень вариант с рестартом

какой то прям watchdog pattern

Есть еще какие-то варианты?

пул jvm-машин, как в nailgun?

ну как бы watchdog и есть вполне себе распространённая практика

которая и реализоваывается с N инстансами процесса

только System.exit не надо в код класть :)

Интересно, помещается ли в головах людей Java и Scala? И не сводит ли это их с ума?)

Скалошники этим наведённым безумием наслаждаются.

как будто Java такая сложная что надо прям много места под нее в башке

/stat@combot

combot.org/chat/-1001043090457

Интересно, помещается ли в головах людей Java и Scala? И не сводит ли это их с ума?)

у людей запросто помещается C++ и Python с Bash-ем. Чоб теперь и Java со Scala не поместить?

как будто Java такая сложная что надо прям много места под нее в башке

Язык то сам не сложный, понятное дело, я про сопуствующие к ЯП либы и прочее)

у людей запросто помещается C++ и Python с Bash-ем. Чоб теперь и Java со Scala не поместить?

более того, у людей помещается хаскель , Си и жава как основные рабочие интсрументы%) и ничего, на жизнь много времени и места остается

более того, у людей помещается хаскель , Си и жава как основные рабочие интсрументы%) и ничего, на жизнь много времени и места остается

и с либами и фреймворками

главное не пытаться в башку все совать что не попадя и что можно прочитать в доках, например API либ

главное не пытаться в башку все совать что не попадя и что можно прочитать в доках, например API либ

почему бы и нет? :)

если когда-то занимался неуправляемым языком, то в голове такая пещера образуется, что туда много что поместится

и с либами и фреймворками

да именно. Я еще про пролог забыл ,в том контексте

А зчем либы еще в голове держать? Я каждый раз вот гуглю на пример как slf4j-sшmple конфигурить.

главное не пытаться в башку все совать что не попадя и что можно прочитать в доках, например API либ

А то возможны коллизии)

почему бы и нет? :)

да есть чисто мусорная информация, например нафиг помнить какое там api у 10 http либ