When to Use TreeSet

Direct Answer

Use TreeSet when the set must stay sorted or needs range and navigation operations such as subSet, floor, ceiling, lower, or higher. Its main operations are O(log n). Use HashSet for expected O(1) membership when order is unnecessary. If sorting is needed only once, a hash set followed by a one-time sort may be simpler, but the best choice depends on update and query patterns.

Code Example

import java.util.TreeSet;

// Stock prices kept sorted automatically
TreeSet<Integer> prices = new TreeSet<>();
prices.add(120); prices.add(75); prices.add(200); prices.add(95);

System.out.println(prices);            // [75, 95, 120, 200] — always sorted
System.out.println(prices.first());    // 75  (cheapest)
System.out.println(prices.last());     // 200 (most expensive)

// Nearest-element lookups (impossible in HashSet)
System.out.println(prices.floor(100));    // 95  -> largest value <= 100
System.out.println(prices.ceiling(100));  // 120 -> smallest value >= 100

// Range query: all prices in [90, 150)
System.out.println(prices.subSet(90, 150)); // [95, 120]

These ordered, range, and nearest-neighbour operations are exactly what justify TreeSet's O(log n) cost over HashSet's O(1).

Common Mistakes & Pitfalls

• Using TreeSet when you only sort once: Freshers see the word sorted and reach for TreeSet, even when they only sort at the end before displaying — use HashSet during processing and call stream().sorted() once, avoiding O(log n) on every add.
• Ignoring the constant factor: O(log n) sounds fine, but for small-to-medium datasets HashSet's O(1) with better cache locality is often faster in practice — don't optimize prematurely.
• Forgetting the Comparable requirement: TreeSet needs elements that implement Comparable, or you must supply a Comparator — add a custom object without either and you get a ClassCastException at runtime.