什么时候（真正）需要不可修改的映射？

Question

我有一个常量映射，如下所示：

private static Map<String, Character> _typesMap =
        new HashMap<String, Character>() {
        {
            put ("string", 'S');
            put ("normalizedString", 'N');
            put ("token", 'T');
            // (...)
        }

我真的需要使用Collections.unmodifyingMap()来创建此映射吗？使用它有什么好处？除了它们并没有真正变得恒定这一明显事实之外，不使用它还有什么缺点吗？

Answer 1

Collections.unmodifyingMap 保证映射不会被修改。如果您想从方法调用返回内部映射的只读视图，那么它非常有用，例如：

class A {
    private Map importantData;

    public Map getImportantData() {
        return Collections.unmodifiableMap(importantData);
    }
}

这为您提供了一种快速方法，不会带来客户端更改数据的风险。它比返回地图副本要快得多，内存效率也更高。如果客户端确实想要修改返回值，那么他们可以自己复制它，但对副本的更改不会反映在 A 的数据中。

如果您不将地图引用返回给其他任何人，则不必费心使其不可修改，除非您偏执于使其不可变。你也许可以相信自己不会改变它。

Answer 2

Cameron Skinner 上面的声明“Collections.unmodifyingMap 保证地图不会被修改”实际上通常只是部分为真，尽管对于问题中的具体示例来说它恰好是准确的（仅因为字符对象是不可变的）。我将用一个例子来解释。

Collections.unmodabilibleMap 实际上只为您提供保护，确保映射中保存的对象的引用无法更改。它通过限制“放入”到它返回的映射中来实现这一点。但是，原始封装的映射仍然可以从类外部进行修改，因为 Collections.unmodifyingMap 不会复制映射内容。

在保罗提出的问题中，幸运的是，地图中保存的角色对象是不可修改的。然而，一般来说这可能不是真的，Collections.unmodifyingMap 所宣传的不可修改性不应该是唯一的保障措施。例如，请参见下面的示例。

import java.awt.Point;
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;

public class SeeminglyUnmodifiable {
   private Map<String, Point> startingLocations = new HashMap<>(3);

   public SeeminglyUnmodifiable(){
      startingLocations.put("LeftRook", new Point(1, 1));
      startingLocations.put("LeftKnight", new Point(1, 2));
      startingLocations.put("LeftCamel", new Point(1, 3));
      //..more locations..
   }

   public Map<String, Point> getStartingLocations(){
      return Collections.unmodifiableMap(startingLocations);
   }

   public static void main(String [] args){
     SeeminglyUnmodifiable  pieceLocations = new SeeminglyUnmodifiable();
     Map<String, Point> locations = pieceLocations.getStartingLocations();

     Point camelLoc = locations.get("LeftCamel");
     System.out.println("The LeftCamel's start is at [ " + camelLoc.getX() +  ", " + camelLoc.getY() + " ]");

     //Try 1. update elicits Exception
     try{
        locations.put("LeftCamel", new Point(0,0));  
     } catch (java.lang.UnsupportedOperationException e){
        System.out.println("Try 1 - Could not update the map!");
     }

     //Try 2. Now let's try changing the contents of the object from the unmodifiable map!
     camelLoc.setLocation(0,0);

     //Now see whether we were able to update the actual map
     Point newCamelLoc = pieceLocations.getStartingLocations().get("LeftCamel");
     System.out.println("Try 2 - Map updated! The LeftCamel's start is now at [ " + newCamelLoc.getX() +  ", " + newCamelLoc.getY() + " ]");       }
}

当您运行此示例时，您会看到：

The LeftCamel's start is at [ 1.0, 3.0 ]
Try 1 - Could not update the map!
Try 2 - Map updated! The LeftCamel's start is now at [ 0.0, 0.0 ]

startingLocations 映射已被封装，并且只能通过利用 getStartingLocations 方法中的 Collections.unmodifyingMap 返回。然而，该方案通过访问任何对象然后更改它而被破坏，如上面代码中的“尝试 2”所示。可以说，如果映射中保存的对象本身是不可变的，则只能依靠 Collections.unmodifyingMap 来提供真正不可修改的映射。如果不是，我们希望复制映射中的对象，或者在可能的情况下限制对对象修饰符方法的访问。

Answer 3

包装 Map 是为了确保调用者不会更改集合。虽然这在测试中很有用，但您确实应该在那里发现这种错误，但它在生产中可能没那么有用。一个简单的解决方法是拥有自己的包装器。

public static <K,V> Map<K,V> unmodifiableMap(Map<K,V> map) {
   assert (map = Collections.unmodifiableMap(map)) != null;
   return map;
}

这仅在断言打开时包装地图。