我最近偶然发现了 Collection.checkedMap 的 Javadoc用于创建标准集合类型的动态类型安全 View 的函数族。考虑到它们在诊断相对常见的程序员错误的集合之上添加了另一层安全性，我认为它们会更受欢迎。但是，出于某种原因，在我参与过的所有大型 Java 项目中，我从未见过它们被使用过一次。
我的问题是:Java 程序员不更频繁地使用这些已检查的包装器是否有特殊原因？或者只是缺乏利益/缺乏对它们存在的了解？
编辑:为了澄清我的问题，集合的通用版本仍然包含类型不安全的函数。 Map的 containsKey , containsValue , remove , 和 get所有操作 Object ， 例如。我的主要问题是，考虑到这种类型不安全，为什么更多人不使用已检查的实现来诊断运行时类型违规。
最佳答案
只有在滥用(或不使用)泛型时，这些类才是真正必要的。它在运行时重复检查，这些检查应该足以通过泛型引擎的类型安全保证在编译时执行。
因此，只有在 API 设计者不信任库的用户并希望保护自己或用户免受用户不当使用 map 的影响时，使用这些方法才真正有趣。
简而言之:如果您的代码编译时没有原始类型警告或任何未经检查的转换/类型警告，您保证 checked* 方法不会给你任何好处；它们只是运行时命中。
编辑
您似乎得出结论，因为 remove、get 等对 Object 进行操作，所以它们在某种程度上是类型不安全的。他们不是。这些方法都不会将其操作数存储在 map 中，因此您当然不会损害 map 本身的类型安全性。这些方法采用 Object 的一个主要原因是:为了向后兼容。从来没有任何严格的要求查找需要坚持同一个类。例如，如果类 A 的实例和类 B 的实例可能以某种方式彼此相等，则将 a 放入映射中，然后调用 remove(b) < em>应该删除a的映射。
一旦添加泛型以保持向后兼容性，就需要支持此行为。因此，他们无法将接口(interface)更新为类似 remove(K) 的东西，因为现有代码可能依赖于能够在给定完全不同类的实例的情况下删除映射。然而，它不是类型不安全的，并且使用 map 的检查版本不会丝毫改变这种行为。
关于java - 为什么不更常用 Collections.checkedMap 和 friend ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4662628/