Какая задача стоит? Что в вашем понятии потокобезопасно?
Удалить одну запись из мапы легко - всего лишь надо вызвать remove(key). Очистить все, так чтобы ни один поток не вклинился, с ConcurrentHashMap у вас не получится, эта структура данных не подходит для этой задачи.

HettЗадача, удалить записи с определенным значением.
Потоки пусть вклиниваются, 2 разных поток могут запросить удаление одного и того же ключа одновременно, в таком случае просто удалить ключи и все.

Зачем тогда этот адский код? В CM есть методы remove(key) и clear(), которые eventually-consistent

Hettзабыл никпропущено...


Зачем тогда этот адский код? В CM есть методы remove(key) и clear(), которые eventually-consistent

Нужно удалить по значению.

Тогда что вас не устраивает в первоначальном варианте?




CM кидает нуллпоинтер на ремуве только когда переданный key == null, а это уже само по себе ошибка, такого быть не должно, но если уж совсем хотите без эксепшенов то добавьте эту проверку e.getKey() != null перед вызовом release.

Оффтопик. static volatile излишни возле обьявления СМ и зачем вы все методы делаете статическими, очень похоже на bad design.

Сергей Арсеньевзабыл никОффтопик. static volatile излишни возле обьявления СМ и зачем вы все методы делаете статическими, очень похоже на bad design.
Не понял Вашего посыла, если честно.
static у TC - простейший вид singleton.
volatile ссылки на объект никак не коррелирует с тем, что из себя представляет объект.

Вопрос к TC - нафига весь огород, если remove и так проверяет тот ли объект пытаемся удалить? Чтоб сделать масло еще масленее?

Когда начинал программировать на java, везде лепил static, я думаю у ТС то же самое, да и синглтон вещь достаточно спорная, но если надо - то ок.
Насчет volatile - она там 200% не нужна, тем более если это сингтон.

HettС удалением действительно намудрил чего-то, первоначальный вариант нормально работал и будет работать.
static, потому что у половина программы в мейн классе. Чем это плохо?

Ну не так уж и плохо. Если это утилита вообще нормально. Если продакшен приложение - я бы обернул все в какой-нибудь сервис, сделал спринговым-бином и инжектил куда надо.
HettПеременная используется в разных потоках, разве volatile это не тот самый случай?

Volatile нужен если значение переменной меняется разными потоками, и вам всегда нужно свежее. В вашем случае CM создается один раз, при classloading, после этого ссылка будет одна и та же и можно не беспокоится. А вот контент мапы меняется, да. Но она сама следит чтобы он был актуальный для разных потоков.

Сергей Арсеньевзабыл никНасчет volatile - она там 200% не нужна, тем более если это сингтон.
Если я чего не путаю, то volatile не мешает многопоточности и в качестве бонуса добавляет например фичу с тем, что из второго потока методы мапы не вызовутся раньше, чем закончит работать ее конструктор. Все ж таки не final поле.
Если это синглтон, то по определению мапа должна быть корректно инициализирована в конструкторе, какие нафиг другие потоки?
Сергей АрсеньевА хуже не сделает.

Ага, мемори барьер при каждом доступе и все оптимизации JIT идут лесом.

Сергей АрсеньевVolatile это не "нужно свежее", это нужно самосогласованное. Упрощенно говоря - при чтении младшие биты будут от той же операции записи, что и старшие (и тем самым добавятся h-b грани - как следствие воспользоваться адресом до окончании инициализации не получится).
При чем тут все это? Красное это красное, да. Очевидно, что ТС влепил volatile не подумав, это распространенная ошибка, когда начинаешь осваивать многопоточность.