Задаю вопрос по человечески. Обнаружил, что аналигичные по своему смыслу методы в совершенно разных по смыслу классах реализованы по разному. Пример:

PriorityBlockingQueue.contains(Object):


ConcurrentHashMap.Segment.containsKey(Object)
     

Не вдаваясь в детали реализации сразу видно, что методы не меняющие состояния объекта (containsKey, containsValue, get) в ConcurrentHashMap лишины какой бы то нибыло синхронизации, в то время как в PriorityBlockingQueue аналогичные (не меняющие состояния очереди)  методы (size(), contains()) синхронизированы. Вопрос почему?

Это сообщение отредактировал(а) Royan - 29.7.2008, 15:11

Я думаю, это связано с внутренней реализацией PriorityQueue
Там оочень важна синхронизация, т.к. есть возможность получить ArrayIndexOutOfBoundsException

Стоит почитать java-doc к этим классам. ConcurrentHashMap не гарантирует синхронность данных. Если операция чтения совпадает с операцией изменения структуры, то ты эти изменения можешь не увидеть. 
Гарантируется только безопасность работы со структурой из нескольких потоков, чего нету у стандартных HashMap'ов. 

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


С доводом не соглашусь, по той причине что и там и там гарантируется безопасность работы в многопоточной среде. Другое дело что для ConcurrentHashMap задокументировано, что операции чтения не синхронизированы: 
К тому же в ConcurrentHashMap были предприняты шаги для того чтобы (даже не знаю как это назвать) увеличить вероятность чтения актуальной информации. О чем это я? Из коментариев к классу java.util.concurrent.ConcurrentHashMap.Segment<K, V>


Поле count объявлено вот так:

Напомню значение модификатора volatile (цитата из JLS3.0)

Теперь, внимание вопрос: Почему аналогичным образом не поступить во всех наследниках AbstractQueue?

Это сообщение отредактировал(а) Royan - 29.7.2008, 17:43

Royan, вы сами и ответили на свой вопрос - реализовано по-разному потому, что это "разные по смыслу классы". Один - очередь на основе связанного списка. Другой - мап, т.е. массив. 

Короче суть в том, что методы записи ConcurrentHashMap, возможно вкупе с методами чтения, реализованы таким образом, что в любой момент переключения потоков, логическая целостность объекта ConcurrentHashMap, как такового(имеется ввиду непротиворечивость состояния внутренних полей), гарантируется. В отличии от объекта класса PriorityQueue, для которого PriorityBlockingQueue является просто синхронизированной обёрткой.

Это сообщение отредактировал(а) ivg - 29.7.2008, 18:54

Я не нахожу ответа на вопрос, почему если мап то можно кое-что не синхронизировать, а если очередь (не важно на какой основе, ибо все что отростает от AbstractQueue синхронизировано вдоль и поперек) так вот если очередь то, как я говорил, надо ее насквозь залочить.

Ну, наверное, потому, что методы, изменяющие обьект, по-разному меняют структуру. Например, при удалении элемента в мапе значение массива в соответствующем индексе просто становится равно null. А в связанном списке при удалении обнуляются ссылки на следующие элементы. Последствия при итерации возможно будут разные, если не синхронизировать. Или еще что-то. Это следствие оптимизации классов с учетом нюансов структуры. 

Похоже на то