假设我正在编写一个应当返回Map的方法。例如：
public Map<String, Integer> foo() {
return new HashMap<String, Integer>();
}
public Map<String, Integer> foo() {
return ImmutableMap.of();
}
我应该将返回类型保留为通用的 Map，还是应该指定我返回的是 ImmutableMap？
一方面，这正是接口创建的原因 —— 隐藏实现细节。
另一方面，如果我保留它如此，其他开发者可能会忽略这个对象是不可变的事实。因此，我不会实现不可变对象的主要目标；通过最小化可以更改的对象数量来使代码更加清晰。更糟糕的是，过一段时间，有人可能尝试更改此对象，而这将导致运行时错误（编译器不会警告）。
如果您正在编写面向公众的API，并且不可变性是设计中重要的方面，我建议通过方法名称清晰地表示返回的映射将是不可变的，或者返回映射的具体类型来明确说明它。在Javadoc中提及它在我看来是不够的。
由于显然您正在使用Guava实现，因此我查看了文档，它是一个抽象类，因此在实际具体类型方面给您一些灵活性。
如果您正在编写内部工具/库，则只返回普通的Map就变得更加可接受。人们将了解他们调用的代码的内部情况，或者至少可以轻松访问。
我的结论是明确的好处多，不要留下任何机会。
Map 接口类型还是 ImmutableMap 实现类型。 - fpsImmutableMap，Guava团队的建议是将ImmutableMap视为具有语义保证的接口，并直接返回该类型。 - Louis WassermanImmutableMap。 Map 包含的方法在 ImmutableMap 的实现中不受支持（例如put），并且被标记为 @deprecated。Collections.immutableMap呢？ - OrangeDogList中一样，没有保证List::add是有效的。尝试使用Arrays.asList("a", "b").add("c")。没有迹象表明它会在运行时失败，但实际上它确实会失败。至少Guava会提前向你发出警告。 - njzk2如果我把它留这样，其他开发者可能会忽略这个对象是不可变的事实。
没错，但其他开发者应该测试他们的代码并确保覆盖到它。
尽管如此，你还有两个解决选项:
使用Javadoc
@return a immutable map
选择一个描述性的方法名称
public Map<String, Integer> getImmutableMap()
public Map<String, Integer> getUnmodifiableEntries()
针对具体的使用情况，您甚至可以更好地命名方法。例如：
public Map<String, Integer> getUnmodifiableCountByWords()
还能做什么？！
你可以返回一个
复制品
private Map<String, Integer> myMap;
public Map<String, Integer> foo() {
return new HashMap<String, Integer>(myMap);
}
如果你预计有许多客户端会修改地图，并且只要地图包含少量条目，就应该使用这种方法。
CopyOnWriteMap
在处理并发时通常使用复制写入集合。但是这个概念也将帮助您解决问题，因为CopyOnWriteMap在变异操作（例如添加、删除）时创建内部数据结构的副本。
在这种情况下，您需要一个薄包装器来委托所有方法调用到基础映射，除了变异操作。如果调用变异操作，它将创建基础映射的副本，并将所有后续调用委托给该副本。
如果您预计某些客户端将修改地图，则应使用此方法。
不幸的是，Java没有这样的CopyOnWriteMap。但是，您可以找到第三方或自己实现它。
最后，请记住，映射中的元素仍然可能是可变的。
一定要返回ImmutableMap，理由如下：
虽然这并没有回答确切的问题，但仍值得考虑是否应该返回地图。如果地图是不可变的，则应基于get(key)提供主要方法：
public Integer fooOf(String key) {
return map.get(key);
}
这使得API更加严密。如果确实需要地图，可以通过提供条目流将其留给API的客户端处理：
public Stream<Map.Entry<String, Integer>> foos() {
map.entrySet().stream()
}
那么客户端可以根据需要创建其自己的不可变或可变映射，或将条目添加到其自己的映射中。如果客户端需要知道该值是否存在，则可以返回Optional:
public Optional<Integer> fooOf(String key) {
return Optional.ofNullable(map.get(key));
}
这取决于类本身。Guava的ImmutableMap并不是旨在成为可变类的不可变视图。如果您的类是不可变的，并且具有基本上是ImmutableMap的某些结构，则将返回类型设置为ImmutableMap。但是，如果您的类是可变的，请不要这样做。如果您有以下内容：
public ImmutableMap<String, Integer> foo() {
return ImmutableMap.copyOf(internalMap);
}
Guava每次都会复制Map，这很慢。但是如果internalMap已经是一个ImmutableMap，那就完全没问题。
如果您不限制类只返回ImmutableMap，那么可以使用Collections.unmodifiableMap代替返回：
public Map<String, Integer> foo() {
return Collections.unmodifiableMap(internalMap);
}
internalMap发生变化，则Collections.unmodifiableMap(internalMap)的缓存副本也会发生变化。但是，我仍然更喜欢将其用于获取器。unmodifiableMap只能被引用持有者修改 - 它是一个视图，支持映射的持有者可以修改支持映射，然后视图会发生变化。所以这是一个重要的考虑因素。 - davidbakCollections.unmodifiableMap时要非常小心。该方法返回一个视图，而不是创建一个单独的新映射对象。因此，引用原始映射的任何其他代码都可以修改它，然后假定不可修改的映射的持有者会从中学习到这个事实。我自己也被这个事实所困扰。我学会了要么返回Map的副本，要么使用Guava的ImmutableMap。 - Basil BourqueImmutable Map 是一种 Map 类型。因此，保留 Map 的返回类型是可以的。
为了确保用户不修改返回的对象，方法的文档可以描述返回对象的特性。
return ImmutableMap.of(somethingElse)。相反，您将把ImmutableMap.of(somethingElse)存储为字段，并仅返回此字段。所有这些都影响了这里的设计。 - Marco13