hack：在java.util.TreeSet中重复吗？

Question

I have a simple class

public class A {
    int val;
    public A(int val) {this.val = val;}
}

I store A instances in a java.util.TreeSet like:

SortedSet<A> ss = new TreeSet<A>(new Comparator<A>() {
    @Override
    public int compare(A o1, A o2) {
        return Integer.compare(o1.val, o2.val);
    }
});

Only to find later that A instances with the same val values cannot coexist in TreeSet .

I need TreeSet because I want:

• Quick Insertion
• Quick Removal
• Quick Query of Element with Minimum val

Since the equality completely depends on the return value 0 of compare() and how we implement it, is there a hacking way that allow instances with the same value of val to coexist in TreeSet ?

My workaround is to return a stable non-zero value if val are equal, but it proves to be unstable.

SortedSet<ListNode> ss = new TreeSet<ListNode>(new Comparator<ListNode>() {
    @Override
    public int compare(ListNode o1, ListNode o2) {
        if (o1.val != o2.val) return Integer.compare(o1.val, o2.val);
        return o1.hashCode() - o2.hashCode(); // not to return 0
    }
});

Or should I just switch to another data structure? (if there exists some substitute better than RB Tree)

And, Oh Geez, I know modeling the mathematical set abstraction is cool and everyone here loves it.

Conclusion : use priority queue .

Answer 1

That's what I wanted to say... why not use a Queue and especially a PriorityQueue that the documentation says to have :

Implementation note: this implementation provides O(log(n)) time for the enqueuing and dequeuing methods: offer, poll, remove and add; linear time for the remove(Object) and contains(Object) methods; and constant time for the retrieval methods, peek, and size.

The diff in PriorityQueue vs Tree is also that the first one is more light-weight as it uses a binary heap as opposed to red-black tree ; so the PriorityQueue will use an array to store it's data that is not that hard to understand.

Also notice that if you populate your PriorityQueue often with high priority tasks - your low priority tasks could wait a lot of time before they are processed.

Answer 2

I suppose you want different A instances to coexist in your set even if they share the same val, and not to add the same A instance more than once.

A a = new A(1);
A b = new A(1);
A c = new A(2);
A d = c;
ss.add(a);
ss.add(b);
ss.add(c);
ss.add(d);

After that, you want ss to contain three instances: two 1 values and one 2 value (because a and b are different instances, c and d contain the same). That is what your code will do (if you don't override the hashCode() method from Object).

Just one improvement: o1.hashCode() - o2.hashCode() might produce arithmetic overflow, better use Integer.compare() for that part, too. Eg 2000000000 - (-2000000000) will give a negative result although the first number is greater. And that will cause all Comparator-based structures to behave strangely.