Hash table and linked list implementation of the {@code Set} interface, * with well-defined encounter order. This implementation differs from * {@code HashSet} in that it maintains a doubly-linked list running through * all of its entries. This linked list defines the encounter order (iteration * order), which is the order in which elements were inserted into the set * (insertion-order). The least recently inserted element (the eldest) is * first, and the youngest element is last. Note that encounter order is not affected * if an element is re-inserted into the set with the {@code add} method. * (An element {@code e} is reinserted into a set {@code s} if {@code s.add(e)} is * invoked when {@code s.contains(e)} would return {@code true} immediately prior to * the invocation.) The reverse-ordered view of this set is in the opposite order, with * the youngest element appearing first and the eldest element appearing last. The encounter * order of elements already in the set can be changed by using the * {@link #addFirst addFirst} and {@link #addLast addLast} methods. * *
This implementation spares its clients from the unspecified, generally * chaotic ordering provided by {@link HashSet}, without incurring the * increased cost associated with {@link TreeSet}. It can be used to * produce a copy of a set that has the same order as the original, regardless * of the original set's implementation: *
{@code
* void foo(Set s) {
* Set copy = new LinkedHashSet<>(s);
* ...
* }
* }
* This technique is particularly useful if a module takes a set on input,
* copies it, and later returns results whose order is determined by that of
* the copy. (Clients generally appreciate having things returned in the same
* order they were presented.)
*
* This class provides all of the optional {@link Set} and {@link SequencedSet} * operations, and it permits null elements. Like {@code HashSet}, it provides constant-time * performance for the basic operations ({@code add}, {@code contains} and * {@code remove}), assuming the hash function disperses elements * properly among the buckets. Performance is likely to be just slightly * below that of {@code HashSet}, due to the added expense of maintaining the * linked list, with one exception: Iteration over a {@code LinkedHashSet} * requires time proportional to the size of the set, regardless of * its capacity. Iteration over a {@code HashSet} is likely to be more * expensive, requiring time proportional to its capacity. * *
A linked hash set has two parameters that affect its performance: * initial capacity and load factor. They are defined precisely * as for {@code HashSet}. Note, however, that the penalty for choosing an * excessively high value for initial capacity is less severe for this class * than for {@code HashSet}, as iteration times for this class are unaffected * by capacity. * *
Note that this implementation is not synchronized. * If multiple threads access a linked hash set concurrently, and at least * one of the threads modifies the set, it must be synchronized * externally. This is typically accomplished by synchronizing on some * object that naturally encapsulates the set. * * If no such object exists, the set should be "wrapped" using the * {@link Collections#synchronizedSet Collections.synchronizedSet} * method. This is best done at creation time, to prevent accidental * unsynchronized access to the set:
* Set s = Collections.synchronizedSet(new LinkedHashSet(...));* *
The iterators returned by this class's {@code iterator} method are * fail-fast: if the set is modified at any time after the iterator * is created, in any way except through the iterator's own {@code remove} * method, the iterator will throw a {@link ConcurrentModificationException}. * Thus, in the face of concurrent modification, the iterator fails quickly * and cleanly, rather than risking arbitrary, non-deterministic behavior at * an undetermined time in the future. * *
Note that the fail-fast behavior of an iterator cannot be guaranteed * as it is, generally speaking, impossible to make any hard guarantees in the * presence of unsynchronized concurrent modification. Fail-fast iterators * throw {@code ConcurrentModificationException} on a best-effort basis. * Therefore, it would be wrong to write a program that depended on this * exception for its correctness: the fail-fast behavior of iterators * should be used only to detect bugs. * *
This class is a member of the
*
* Java Collections Framework.
*
* @param The {@code Spliterator} reports {@link Spliterator#SIZED},
* {@link Spliterator#DISTINCT}, and {@code ORDERED}. Implementations
* should document the reporting of additional characteristic values.
*
* @implNote
* The implementation creates a
* late-binding spliterator
* from the set's {@code Iterator}. The spliterator inherits the
* fail-fast properties of the set's iterator.
* The created {@code Spliterator} additionally reports
* {@link Spliterator#SUBSIZED}.
*
* @return a {@code Spliterator} over the elements in this set
* @since 1.8
*/
@Override
public Spliterator
* If this set already contains the element, it is relocated if necessary so that it is
* first in encounter order.
*
* @since 21
*/
public void addFirst(E e) {
map().putFirst(e, PRESENT);
}
/**
* {@inheritDoc}
*
* If this set already contains the element, it is relocated if necessary so that it is
* last in encounter order.
*
* @since 21
*/
public void addLast(E e) {
map().putLast(e, PRESENT);
}
/**
* {@inheritDoc}
*
* @throws NoSuchElementException {@inheritDoc}
* @since 21
*/
public E getFirst() {
return map().sequencedKeySet().getFirst();
}
/**
* {@inheritDoc}
*
* @throws NoSuchElementException {@inheritDoc}
* @since 21
*/
public E getLast() {
return map().sequencedKeySet().getLast();
}
/**
* {@inheritDoc}
*
* @throws NoSuchElementException {@inheritDoc}
* @since 21
*/
public E removeFirst() {
return map().sequencedKeySet().removeFirst();
}
/**
* {@inheritDoc}
*
* @throws NoSuchElementException {@inheritDoc}
* @since 21
*/
public E removeLast() {
return map().sequencedKeySet().removeLast();
}
/**
* {@inheritDoc}
*
* Modifications to the reversed view are permitted and will be propagated to this set.
* In addition, modifications to this set will be visible in the reversed view.
*
* @return {@inheritDoc}
* @since 21
*/
public SequencedSet