// normal list
    List list1 = new ArrayList();
    list1.add(1);

    // unmodifiable list
    List list2 = Collections.unmodifiableList(list1);

    // immutable list
    List list3 = Collections.unmodifiableList(new ArrayList<>(list1));

    list1.add(2);
    list1.add(3);

    System.out.println(list1);
    System.out.println(list2);
    System.out.println(list3);

输出:

[1, 2, 3]
[1, 2, 3]
[1]

Java™教程介绍了以下内容:

Unlike synchronization wrappers, which add functionality to the wrapped collection, the unmodifiable wrappers take functionality away. In particular, they take away the ability to modify the collection by intercepting all the operations that would modify the collection and throwing an UnsupportedOperationException. Unmodifiable wrappers have two main uses, as follows: To make a collection immutable once it has been built. In this case, it's good practice not to maintain a reference to the backing collection. This absolutely guarantees immutability. To allow certain clients read-only access to your data structures. You keep a reference to the backing collection but hand out a reference to the wrapper. In this way, clients can look but not modify, while you maintain full access.

我认为这是一个很好的解释，足以理解其中的区别。

如上所述，不可修改的不像不可变的，因为不可修改的集合可以被改变，例如，如果一个不可修改的集合有一个被其他对象引用的底层委托集合，而该对象改变了它。

Regarding immutable, it's not even well defined. However, generally it means that the object "will not change", but that would need to be defined recursively. For example, I can define immutable on classes whose instance variables are all primitives and whose methods all contain no arguments and return primitives. The methods then recursively allow the instance variables to be immutable and all methods to contain arguments that are immutable and that return immutable values. The methods should be guaranteed to return the same value over time.

Assuming that we can do that, there is also the concept thread safe. And you might be led to believe that immutable (or not changeble over time) also implies thread safe. However that is not the case and that is the main point I am making here that has not yet been noted in other answers. I can construct an immutable object that always returns the same results yet is not thread safe. To see this suppose that I construct an immutable collection by maintaining additions and deletions over time. Now the immutable collection returns its elements by looking at the internal collection (which may be changing over time) and then (internally) adding and deleting the elements that were added or deleted after creation of the collection. Clearly, although the collection would always return the same elements, it is not thread safe merely because it will never change value.

现在我们可以将不可变定义为线程安全且永远不会改变的对象。有一些创建不可变类的指导原则，这些类通常会导致这样的类，然而，请记住，可能有一些创建不可变类的方法，需要注意线程安全，例如，如上面的“快照”集合示例所述。

不可修改的和不可变的集合

创建一个可修改的地图

Map<String, String> modifiableMap = new HashMap();
modifiableMap.put(“1”,”one”);
modifiableMap.put(“2”,”two”);
modifiableMap.put(“3”,”three”);

从modifiableMap中创建一个unmodifiableMap

 Map<String,String> unmodifiableMap = Collections.unmodifiableMap(modifiableMap);
    unmodifiableMap.put(“4”,”Four”)  ==>Exception
    modifiableMap.put(“4”,”Four”);   ==>Allowed, this will also reflect now in the unmodifiableMap , because unmodifiableMap() returns a wrapper around modifiableMap.
     

从modifiableMap创建一个immutableMap

 Map<String,String> immutableMap = Collections.immutableMap(modifiableMap);
    immutableMap.put(“5”,”Five”) ==>Exception
    modifiableMap.put(“5”,”Five”);   ==>Allowed, BUT this will NOT reflect now in the immutableMap, because immutableMap() returns a copy of the modifiableMap.

我认为主要的区别是，可变集合的所有者可能希望向其他一些代码提供对集合的访问，但通过不允许其他代码修改集合的接口提供这种访问(同时将这种能力保留给所有者代码)。因此集合不是不可变的，但某些用户不允许更改集合。

Oracle的Java Collection Wrapper教程有这样说(强调添加):

不可修改的包装器有以下两个主要用途: 使集合在构建后不可变。在这种情况下，最好不要维护对后台的引用 收集。这绝对保证了不变性。 允许某些客户端只读访问您的数据结构。您保留了对备份集合的引用 输出对包装器的引用。这样，客户可以看，但不能看 修改，同时保持完全访问权限。

引用Java™教程:

Unlike synchronization wrappers, which add functionality to the wrapped collection, the unmodifiable wrappers take functionality away. In particular, they take away the ability to modify the collection by intercepting all the operations that would modify the collection and throwing an UnsupportedOperationException. Unmodifiable wrappers have two main uses, as follows: To make a collection immutable once it has been built. In this case, it's good practice not to maintain a reference to the backing collection. This absolutely guarantees immutability. To allow certain clients read-only access to your data structures. You keep a reference to the backing collection but hand out a reference to the wrapper. In this way, clients can look but not modify, while you maintain full access.

(强调我的)

这真的很概括。