先看一个例子：

执行结果：

    那么为什么会出现这样的结果呢？对于Unmodifiable的List不能做修改很好理解，但从结果中可以看到，同样是ArrayList，为什么Array.asList()返回的List就不能做修改呢？

    Arrays.asList()会生成一个List，它基于一个固定大小的数组，仅支持那些不会改变数组大小的操作，任何对引起底层数据结构的尺寸进行修改的方法都会产生一个UnsupportedOperationException异常，以表示对未获支持操作的调用。

    其实上面的代码中，我故意使用的是getSimpleName()，因为这个方法不会显示包名。如果我们将

    替换为：

    那么结果就是这样的了：

    可以看到，Arrays.asList返回的名字虽然叫ArrayList，但此ArrayList是Arrays中的一个内部类，而非java.util.ArrayList。

查看其源码，可以发现此Arrays.ArrayList内部类的声明如下：

    而该类的实现方法中，并没有实现修改E[]数组（增、删、清除等）的方法

    因此对这种对象调用这些方法时会调用AbstractList类中的实现，于是就直接抛出了UnsupportedOperationException：

    因此，通常的做法是，把Arrays.asList()的结果作为构造方法的参数传递给任何Collection（或者使用addAll()方法或Collections.addAll()静态方法），这样就可以生成允许使用所有的方法的普通容器——这在main()中的第一个对test()的调用中得到了展示，这样的调用会产生新的尺寸可调的底层数据结构。Collections类的“不可修改”方法将容器包装到了一个代理中，只要你执行任何试图修改容器的操作，这个代理就会产生UnsupportedOperationException异常。使用这些方法的目标就是产生“常量”容器对象。

    test()中的最后一个try语句块将检查作为List的一部分set()方法。Arrays.asList()返回固定尺寸的List，而Collections.unmodifiableList()产生不可修改的列表。正如输出中看到的，修改Arrays.asList()返回的List中的元素是可以的，因为这没有违反“尺寸固定”这一特性。但很明显，unmodifiableList()的结果在任何情况下都是不可修改的。

--------------------------------------------------------------

    像上述抛出异常的操作，在Java容器中被称为“未获支持的操作”。那么为什么会将方法定义为可选的呢？那是因为这样做可以防止在设计中出现接口爆炸的情况。为了让这种方式能工作：

    1. UnsupportedOperationException必须是一种罕见的事件。即，对于大多数类来说，所有操作都应该可以工作，只有在特例中才会有这类操作。在Java容器中也确实如此，因为你在99%的时间里使用的容器类，如ArrayList、LinkedList、HashSet和HashMap，以及其他的具体实现，都支持所有的操作。

    2. 如果一个操作是未获支持的，那么在实现接口的时候可能就会导致UnsupportedOperationException异常，而不是将产品交付给客户以后才出现此异常，这种情况是有道理的，毕竟，它表示编程上有错误：使用了不正确的接口实现。

    值得注意的是，这类操作只有在运行时才能探测到。