集合的實际应用.docxVIP

集合的实际应用：PlantsByWebSphere 和 WebSphere Application Server Version 7在 表1中，创建一个包含 10,000 个条目、基于 Hash 的集合的开销是 360K。考虑到，复杂的 Java 应用程序常常使用大小为数 GB 的 Java 堆运行，因此这样的开销看起来并不是非常高，当然，除非使用了大量集合。 表 1 展示了在包含五个用户的负载测试中运行 WebSphere? Application Server Version 7 提供的 PlantsByWebSphere 样例应用程序时，Java 堆使用的 206MB 中的集合对象使用量： 表 1. WebSphere Application Server v7 中的 PlantsByWebSphere 的集合使用量集合类型实例数量集合总开销 (MB)Hashtable262,23426.5WeakHashMap19,56212.6HashMap10,6002.3ArrayList9,5300.3HashSet1,5511.0Vector1,2710.04LinkedList1,1480.1TreeMap2990.03总计306,19542.9通过表 1可以看到，这里使用了超过 30 万个不同的集合，而且仅集合本身（不考虑其中包含的数据）就占用了 206MB 的 Java 堆用量中的 42.9MB（21%）。这就意味着，如果您能更改集合类型，或者确保集合的大小更加准确，那么就有可能实现可观的内存节约。 通过 Memory Analyzer 查找低填充率IBM Java 监控和诊断工具（Memory Analyzer 工具是在 IBM Support Assistant 中提供的）可以分析 Java 集合的内存使用情况。其功能包括分析集合的填充率和大小。您可以使用这样的分析来识别需要优化的集合。 Memory Analyzer 中的集合分析位于 Open Query Browser - Java Collections 菜单中，如图 2 所示： 图 2. 在 Memory Analyzer 中分析 Java 集合的填充率在判断当前大小超出需要的大小的集合时，图 2 中选择的 Collection Fill Ratio 查询是最有用的。您可以为该查询指定多种选项，这些选项包括： 对象：您关注的对象类型（集合） 分段：用于分组对象的填充率范围将对象选项设置为 java.util.Hashtable、将分段选项设置为 10，之后运行查询将得到如图 3 所示的输出结果：图 3. 在 Memory Analyzer 中对 Hashtable 的填充率分析图 3表明，在 java.util.Hashtable 的 262,234 个实例中，有 127,016 (48.4%) 的实例完全未空，几乎所有实例都仅包含少量条目。 随后便可识别这些集合，方法是选择结果表中的一行，右键单击并选择 list objects - with incoming references，查看哪些对象拥有这些集合，或者选择 list objects - with outgoing references，查看这些集合中包含哪些条目。图 4展示了查看对于空 Hashtable 的传入引用的结果，图中展开了一些条目： 图 4. 在 Memory Analyzer 中对于空 Hashtable 的传入引用的分析 图 4 表明，某些空 Hashtable 归 javax.management.remote.rmi.NoCallStackClassLoader 代码所有。通过查看 Memory Analyzer 左侧面板中的 Attributes 视图，您就可以看到有关 Hashtable 本身的具体细节，如图 5 所示： 图 5. 在 Memory Analyzer 中检查空 Hashtable 图 5表明，Hashtable 的大小为 11（默认大小），而且完全是空的。对于 javax.management.remote.rmi.NoCallStackClassLoader 代码，可以通过以下方法来优化集合使用： 延迟分配 Hashtable：如果 Hashtable 为空是经常发生的普遍现象，那么仅在存在需要存储的数据时分配 Hashtable 应该是一种合理的做法。 将 Hashtable 分配为准确的大小：由于使用默认大小，因此完全可以使用更为准确的初始大小。这些优化是否适用取决于代码的常用方式以及通常存储的是哪些数据。 PlantsByWebSphere 示例中的空集合表 2 展示了分析 PlantsByWebSphere 示例中的集合来确定哪些集合为空时的分