From today on, I want to sum up again what java has to do with collections. It's convenient for me to review. Besides, spring moves are also here. It's terrible. I want to learn them seriously. I can't learn from the epidemic. It's beautiful.
Well, there's no more nonsense. Let's take a look at a picture first

This is the most common diagram in the Collection. All kinds of classes and interfaces are on it. As you can see, the top layer is Iterator, followed by Collection and ListIterator. Let's not talk about the list Iterator. Let's take a look at the other two for the moment, and take a look at them 😄😄😄😄😄😄😄😄👨👨👨👨👨
GOGOGOGO～～～～

Iterator

Iterators act on collections and are objects used to traverse collection elements. Iterators are not unique to Java. Most high-level languages provide iterators to traverse collections. In fact, an iterator is a design pattern:

Iterators encapsulate the traversal of sets, so that different sets can be traversed in the same way without knowing the internal details of the sets.

Don't say anything, just look at the source code:

public interface Iterator<E> {
    /**
     * This method is generally used before the next method to determine whether there are elements in the iterator
     * 
     */
    boolean hasNext();

    /**
     *Return to next element
     *If there is no element already, @ throws NoSuchElementException 
     */
    E next();

    /**
     * Remove the last call to the next method to return an element, that is, it is closely related to the next method. If you do not call next before, you will make an error.
   
     */
    default void remove() {
        throw new UnsupportedOperationException("remove");
    }

    /**
     * 
     * This method is only available in JDK 1.8. This method can be called and passed in a lambda expression, which is equivalent to traversing without writing a loop, and then operating according to the logic of lambda
     * 
     */
    default void forEachRemaining(Consumer<? super E> action) {
        Objects.requireNonNull(action);
        while (hasNext())
            action.accept(next());
    }
}

foreachRemaining method use

Of course, each collection implementation may be different, so let's summarize.

Insert a small remark

Look at this.

In the top figure, it seems that Collection has something to do with Iterator, but now it has something to do with iteratable. Look at the source code to see what's going on. Let's see Iterable

Iterable

public interface Iterable<T> {
    /**
     *To implement the interface method, we can return iterators, so it's clear here that iteratable has a method to return iterators that we need to implement.
     */
    Iterator<T> iterator();

    /**
     * This is a syntax sugar of jdk1.8. This method will iterate the elements in the compilation phase, but we can still use foreach to use it
     *
     *In fact, it has the same effect as this form, which is the default implementation.
     *     for (T t : this)
     *         action.accept(t);
     * 		}  
     */
    default void forEach(Consumer<? super T> action) {
        Objects.requireNonNull(action);
        for (T t : this) {
            action.accept(t);
        }
    }

    /**
     * 
     */
    default Spliterator<T> spliterator() {
        return Spliterators.spliteratorUnknownSize(iterator(), 0);
    }
}

In the above code, we can see that iterator method of iteratable returns iterator. So the relationship is clear
Let's take a closer look at the Collection interface

Collection

Wow, it turns out that the Collection interface inherits the Iterable interface, so if the Collection interface should be implemented, the iterator method should be implemented, so that you can get an iterator. But this iterator method is not implemented. Don't worry. I'll see in the future. Only the Collection interface today

public interface Collection<E> extends Iterable<E> {
      /**
     * Returns the size of the collection
     */
    int size();    
    boolean isEmpty();   
    boolean contains(Object o);
    Iterator<E> iterator();
    Object[] toArray();
    <T> T[] toArray(T[] a);
    boolean add(E e);

 
    boolean remove(Object o);  
    boolean containsAll(Collection<?> c);    
    boolean addAll(Collection<? extends E> c);
    boolean removeAll(Collection<?> c);  
    default boolean removeIf(Predicate<? super E> filter) {
        Objects.requireNonNull(filter);
        boolean removed = false;
        final Iterator<E> each = iterator();
        while (each.hasNext()) {
            if (filter.test(each.next())) {
                each.remove();
                removed = true;
            }
        }
        return removed;
    }
    
    boolean retainAll(Collection<?> c);


    void clear();


    // Comparison and hashing

   
  //Emphasis on hashcode and equals methods
    boolean equals(Object o);   
    int hashCode();   
   
    @Override
    default Spliterator<E> spliterator() {
        return Spliterators.spliterator(this, 0);
    }

 
    default Stream<E> stream() {
        return StreamSupport.stream(spliterator(), false);
    }

    default Stream<E> parallelStream() {
        return StreamSupport.stream(spliterator(), true);
    }
}

There are not many lines in the source code. The purpose is to find out the relationship among the three. Next, we will go deep into other interfaces, abstract classes and implementation classes.