我遇到一种情况，其中许多键都指向一个值。这种情况是由于我正在实施的服务定位器模式引起的-
接口中的每个方法都表示为签名字符串
单个接口的所有此类签名均用作密钥
该值是实现类的完整规范名称
因此，我需要在用户请求任何匹配键时检索单个值。
从某种意义上说，我需要Guava的MultiMap的反面。
我正在寻找最优化的解决方案，因为我的键非常相似，尽管对于特定值来说是唯一的，并且我不确定使用像HashMap这样的通用Map实现是否足以处理这种情况。
例如以下所有签名
==============
_org.appops.server.core.service.mocks.MockTestService_testOperation三
_org.appops.server.core.service.mocks.MockTestService_getService
_org.appops.server.core.service.mocks.MockTestService_start
_org.appops.server.core.service.mocks.MockTestService_testOperationTwo_String_int
_org.appops.server.core.service.mocks.MockTestService_getName
_org.appops.server.core.service.mocks.MockTestService_shutdown
_org.appops.server.core.service.mocks.MockTestService_testOperationOne_String
=======
指向单个类，即org.appops.server.core.service.mocks.MockTestServiceImpl，而我预计会有数百个此类（值）和数千个此类相似的签名（键）。
万一没有优化的方法，我总是可以使用HashMap并为每个要避免的键组使用重复的值。
理想情况下，我想使用Guava提供的现成实用程序。
最佳答案
HashMap实际上是您所需要的，问题是您误解了它的作用。
万一没有优化的方法，我总是可以使用HashMap并为每个要避免的键组使用重复的值。HashMap不会为每个映射到该值的键存储该值的副本。 HashMap存储对Java对象的引用。费用总是一样的。每个键都映射到相同HashMap<Integer, BigExpensiveObject>的BigExpensiveObject占用的内存量与每个键都映射到相同HashMap<Integer, Integer>的Integer完全相同。整个程序中唯一的内存差异将是一个BigExpensiveObject和一个Integer之间的内存差异。