Проверка работоспособности динамического набора

У меня есть объект QueueSet из ConcurrentSkipListSet в Java

Имейте в виду, что, в отличие от большинства коллекций, метод size не является операцией с постоянным временем. Из-за асинхронной природы этих наборов определение текущего количества элементов требует обхода элементов, и поэтому может сообщать о неточных результатах, если эта коллекция изменяется во время обхода. Кроме того, не гарантируется атомарное выполнение массовых операций addAll, removeAll, keepAll, containsAll, equals и toArray. Например, итератор, работающий одновременно с операцией addAll, может просматривать только некоторые добавленные элементы.

Проблема: в этом if(!activeQueueSet.add(queue)) есть ошибочная проверка работоспособности, но, как вы можете видеть из документации, это операция O(n), т.е. просматривается весь набор, который каким-то образом неправильно интерпретирует состояние списка довольно много раз. Я ищу надежную проверку здравомыслия по этому поводу.


java queue concurrency sanity-check
person Ayush    schedule 03.08.2016    source источник
comment
Мне непонятно, о чем вы спрашиваете. Какое отношение имеет тот факт, что size не является операцией с постоянным временем, к проверке того, возвращает ли метод add правильное значение?   -  person Brett Okken    schedule 04.08.2016

Ответы (1)


arrow_upward
1
arrow_downward

Это правда, что ваш ConcurrentSkipListSet.add(element) может возвращать true или false в зависимости от того, одновременно ли модифицируется набор другим потоком с помощью итератора, который здесь слабо согласованный или массовыми методами (например, xxxAll()), которые не являются атомарными.

Однако помните, что методы add() и remove() являются потокобезопасными, поэтому пока вы изменяете свой набор, используя только их, все будет в порядке.

Что с этим делать, зависит от вашего конкретного приложения. Если элемента не было, но он добавился, это хорошо. Так ли уж плохо, если элемент был там изначально и поэтому не добавлен?

Вы можете разработать класс, содержащий (или, возможно, расширяющий) ConcurrentSkipListSet с очень контролируемым API, предотвращающим любые проблемные операции или делающим их потокобезопасными с помощью блокировок.

person diginoise    schedule 03.08.2016
comment
Это не так уж плохо и случается очень редко, но все же это то, что нужно решать. Думаю, ваша идея с расширением сработает. - person Ayush; 04.08.2016