I have an object QueueSet made from ConcurrentSkipListSet in Java
Beware that, unlike in most collections, the size method is not a constant-time operation. Because of the asynchronous nature of these sets, determining the current number of elements requires a traversal of the elements, and so may report inaccurate results if this collection is modified during traversal. Additionally, the bulk operations addAll, removeAll, retainAll, containsAll, equals, and toArray are not guaranteed to be performed atomically. For example, an iterator operating concurrently with an addAll operation might view only some of the added elements.
Problem: There is flawed sanity check on this if(!activeQueueSet.add(queue)) but as you can see from the documentation its a O(n) operation i.e. the whole set is traversed which somehow misinterprets the state of the list quite a lot of times. I'm looking for a foolproof sanity check on this.
It is true that your ConcurrentSkipListSet.add(element) can return true or false depending on whether the set is being simultaneously modified by another thread using iterator, which here is weakly consistent, or by bulk methods (i.e. xxxAll()) which are not atomic.
Please mind however that add() and remove() methods are thread safe, so as long as you modify your set using only these you will be fine.
It will be down to your specific application what to do about it. If the element was not there, but got added, that's good. Is it so bad if the element was there in the first place and therefore not added?
You can devise a class containing (or perhaps extending) ConcurrentSkipListSet with very controlled API preventing any of the problematic operations or making them thread safe by using locks.