在值中存储TreeMap的键（java）

Question

TreeMap由Key, Value对实例化。 对我来说， Key是一个IP地址， Value是包含有关该IP地址的统计信息的对象。

是否有过一个理由冗余存储的Key里面Value目标？ 我很想节省空间并将其遗漏，但直观地认为没有Key在对象内部（为了良好的封装）是错误的。

Answer 1

请记住，包含密钥只会将值对象的大小增加32位或64位（取决于您使用的是32位还是64位JVM），因此决定是否包含它可能不会对你的程序的内存消耗产生重大影响 - 因此我会错误地包含它而不是不包括它。

Answer 2

你的设计存在缺陷 - 你处于“拒绝对象”状态。

您应该创建一个类来保存详细信息，包括IP地址。

如果您希望快速检索给定IP地址的详细信息，则可以使用IP地址作为密钥将它们存储在Map中。

在某种程度上，这就是你所要求的，因为地图中使用的密钥存储在值对象中。 只是通过适当的设计，密钥已经是存储在值中的对象的一部分。

Answer 3

有没有理由在Key对象中冗余地存储Key？

首先，您不会将值存储在值对象“内部”。 相反，值对象将具有对关键对象的引用。 因此，您根本不存储冗余副本。 （或者至少，除非你故意复制/克隆关键对象......这将是相当愚蠢的。）

唯一的问题是对值对象中的键的引用是否是“冗余的”。 从某种意义上说，它是，但另一方面，冗余可能会简化您的代码......并可能使其在其他地方更有效。 我们无法在不查看代码中如何使用这些对象（其他地方）的情况下做出判断。 但无论如何它的可能性并没有多大差别; 见下文。

我很想节省空间并将其遗漏，但直观地认为没有Key在对象内部（为了良好的封装）是错误的。

没有引用值中的键的空间节省是每个值一个字（32或64位）。 即使您有数百万这些对象，这也很可能太小而无法担心。 实际情况是，对于给定的键+值+映射条目，一个额外的单词可能小于整个每对象空间使用的5％ 。 这5％不太可能产生重大影响......

封装问题取决于上下文。 这实际上取决于封装边界的位置，以及它们的多孔性。 封装不是最终目标。 它是可用于设计/实现可维护软件的一组“工具”之一。 它并不总是正确的工具，它必须得到适当的使用; 即清楚地了解它如何帮助（或阻碍）手头的问题。

但是这里有一个想法：你可以将“值”对象作为Map的键和值...并使用Comparator 。 根据细节，这将允许您完全隐藏封装边界内的IP地址（等）。 （虽然这种方法不适用于HashMap ...）

---

最后一条建议。

您似乎正在做有经验的开发人员认为“过早优化”的事情。 这通常是一个坏主意。 我的建议是暂时不要担心空间使用情况。

• 等到应用程序正常运行，您就可以对实际输入数据进行基准测试。

• 基准测试并查看性能（即内存使用情况）是否可接受。

• 如果（并且仅当）它是不可接受的，请分析应用程序以寻找减少内存使用的机会。

• 实施并重新运行基准，看它是否有所作为。

• 根据需要重复。

Answer 4

如果密钥将在​​应用程序中的任何其他位置使用（如果是值对象），那么将其保留在对象内是个好主意