分析过Immutable Collections后，进入具体的数据结构来分析，这一次我们来看看ImmutableList。作为线性可重复集合，ImmutableList的底层实现采用了数组，因为不可变集合，就不存插入删除的操作。数组的下标使得根据index的read的操作，时间复杂度变为了O(1)。对于ImmutableList的两种实现，我们先来看下UML图。

首先，我们看下构造一个ImmutableList的方法

@Test
public void constructImmutableList() {
   　ImmutableList<Integer> list1 = ImmutableList.of(1, 2, 3, 4);
     ImmutableList<Integer> list2 = ImmutableList.copyOf(Lists.newArrayList(1, 2, 3, 4));
}

首先of()方法被重载了12次(后文会详细介绍原因)，of()方法的实现，根据参数个数的不同，采用了不同的实现，1个参数为

public static <E> ImmutableList<E> of(E element) {
    return new SingletonImmutableList<E>(element);
 }

根据SingletonImmutableList的内部实现可以看出，对于一个元素的ImmutableList，Guava并没有在内部维护一个数组，而是维护了一个元素，而其他的操作都会针对，单个元素进行了优化，例如contains()方法的实现变为了equals的比较。具体代码如下：

final class SingletonImmutableList<E> extends ImmutableList<E> {

     final transient E element;

     @Override public boolean contains(@Nullable Object object) {
         return element.equals(object);
     }
}

多个参数的of()方法实现，都会依赖于construct()方法

private static <E> ImmutableList<E> construct(Object... elements) {
    return asImmutableList(checkElementsNotNull(elements));
 }

而construct()方法最终依赖于asImmutableList()方法实现，代码如下：

static <E> ImmutableList<E> asImmutableList(Object[] elements, int length) {
    switch (length) {
      case 0:
        return of();//直接返回空数组
      case 1:
        @SuppressWarnings("unchecked") // collection had only Es in it
        ImmutableList<E> list = new SingletonImmutableList<E>((E) elements[0]);//返回SingletonImmutableList，上面分析过
        return list;
      default:
        if (length < elements.length) {//of方法的length和elements.length都是相等的
          elements = arraysCopyOf(elements, length);
        }
        return new RegularImmutableList<E>(elements);
    }
}

RegularImmutableList内部维护Object数组，对于集合接口的实现，全部依赖于对数组下标和偏移量的实现

class RegularImmutableList<E> extends ImmutableList<E> {
  private final transient int offset;
  private final transient int size;
  private final transient Object[] array;

  RegularImmutableList(Object[] array, int offset, int size) {
    this.offset = offset;
    this.size = size;
    this.array = array;
  }

  RegularImmutableList(Object[] array) {
    this(array, 0, array.length);
  }

  @Override
  @SuppressWarnings("unchecked")
  public E get(int index) {
    Preconditions.checkElementIndex(index, size);
    return (E) array[index + offset];//对于集合的操作，全部转换为对数据的index和offset的操作，时间复杂度变为O(1)
  }

}

其中有一个方法实现的非常巧妙，subListUnchecked()方法，实现并没有构造新的Object[]数组，而是在利用原有的数组，但偏移量有所改变。所有的写操作都已经被屏蔽，所以Object[]数组成为了不可变，截取操作只是变成了对原有Object[]上下界的操作。节省了很多空间

ImmutableList<E> subListUnchecked(int fromIndex, int toIndex) {
    return new RegularImmutableList<E>(
        array, offset + fromIndex, toIndex - fromIndex);
 }

仔细的童鞋可以发现，ImmutableList的of()方法，被重载了12次，为什么Guava的设计者不适用可变参数列表呢？原因在于，改进使用带泛型可变参数的方法时的编译器警告和错误提示，如果在泛型与可变参数列表同时适用会产生编译警告和堆污染，Guava自己重载了11次of方法，根据不同的参数个数，而且建议你of方法一次性传11个参数就可以了(良好的代码书写，告诉我们不要这样做)。

另一个需要分析的就是ImmutableList的copyOf方法，如果copyOf的传参是一个ImmutableCollection（非部分视图），其实并没有真正的进行了copy操作，如果是非ImmutableCollection，那么，就会进行真正的copy。

public static <E> ImmutableList<E> copyOf(Collection<? extends E> elements) {
    if (elements instanceof ImmutableCollection) {
      @SuppressWarnings("unchecked") // all supported methods are covariant
      ImmutableList<E> list = ((ImmutableCollection<E>) elements).asList();
      return list.isPartialView()
          ? ImmutableList.<E>asImmutableList(list.toArray())//isPartialView==true，进行copy
          : list;//直接返回，因为不可变
    }
    return construct(elements.toArray());//进行copy
  }