当前位置：文江博客话题详情

如何在组件的设计阶段防止内存泄漏？

发布于 2024-11-05 00:53:57 字数 281 浏览 1 评论 0原文

我正在开发一个基于 Web 的组件，该组件将用 Java 开发。一部分是基于webservices，另一部分是Spring-MVC框架和Hibernate作为持久层。

我仍在设计过程中 - 准备用例、活动图和序列图。

我只是想知道 - 有什么具体方法可以确保设计本身不存在可能导致内存泄漏的东西。遵循正确的编码指南并进行代码审查可以确保程序中不存在内存泄漏，但设计级别又如何呢？我们是否有一些方法来设置上限，以便开发人员不必发挥他的想象力并防止泄漏。

感谢任何建议。

谢谢，乌杰瓦尔

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

狼性发作 2024-11-12 00:53:57

大多数内存泄漏是由实现错误引起的，在 Java 中，大多数内存泄漏是由于对所使用的技术没有充分了解而导致的。（例如 4 种不同类型的内部类）

唯一有帮助的方法是花费时间和金钱来提高开发人员的技能。 - 最佳读物 Joshua Bloch 的《Effective Java Second Edition》

另一个经常导致内存泄漏的领域是并发。 - 据我所知，处理这个问题（以及其他并发问题）的最佳方法是在实现它们之前定义哪些组件需要保存（以及哪些在单线程环境中运行）。如果它们需要实现线程保存，那么在实现之前定义它们到底是谁，确保它们是线程保存的（哪个函数和方法由什么保护）。

在设计中你能做的最后一件事是注意静态字段。

您认为可以通过设计做的另一件事是构建一个看门狗。如果您有（例如）一个动态列表，当列表中的某些项目丢失时，这不是一个大问题，并且您知道该列表可能是导致某些问题（线程或实现失败）的原因，那么实现一个如果列表变得比您预期的大得多，看门狗会清除列表。（然后：修复导致问题的错误！） - 此类列表的一个示例可以是证券交易所 GUI 更新事件列表（在与股票无关的网站中）。如果一个课程更新没有发送到客户端，而是发送下一个（一秒后），那么丢失一个更新比整个服务器崩溃要好得多。

回复收藏 0 原文

醉态萌生 2024-11-12 00:53:57

java中最常见的内存泄漏情况之一是缓存：

Map<String, Connection> userConnection = new HashMap<String, Connection>();
// cache connections:
userConnection.put("User X", connectionInstance);
// connectionInstance is closed but never the userConnection.remove("User X") is called.

当连接关闭时，该映射没有被清除，从而出现内存泄漏。

回答您的问题，请提供使用 WeakHashMap 的指南（ http://download.oracle.com/javase/6/docs/api/java/util/WeakHashMap.html ）用于缓存而不是使用“普通”HashMap。

One of the most common case of memory leak at java is with caching:

Map<String, Connection> userConnection = new HashMap<String, Connection>();
// cache connections:
userConnection.put("User X", connectionInstance);
// connectionInstance is closed but never the userConnection.remove("User X") is called.

When the connection is closed, this mapping is not cleared, having a memory leak.

Answering your question, put at your guide lines to use WeakHashMap ( http://download.oracle.com/javase/6/docs/api/java/util/WeakHashMap.html ) for caching rather than to use the "normal" HashMap.

回复收藏 0 原文

趴在窗边数星星i 2024-11-12 00:53:57

您应该关心的不仅仅是内存。线程、文件和网络连接等资源也需要考虑。

我可以推荐您阅读面向模式的软件架构，第 3 卷：资源管理模式这本书。它包含一些需要考虑的有用模式。

回复收藏 0 原文

ι不睡觉的鱼゛ 2024-11-12 00:53:57

我不相信你可以在设计阶段防止内存泄漏。然而，使用 JMeter/Grinder/Loadrunner 等传统负载测试工具可以帮助发现内存泄漏，以便在发布之前修复它们。

性能测试应该涉及到开发过程的每一步，就像单元测试和集成测试一样。

回复收藏 0 原文

倾城花音 2024-11-12 00:53:57

加载系统只是发现资源泄漏的挑战的一半。第二个挑战是拥有适当的监视器和诊断实用程序系统，以了解资源的使用情况以及潜在的影响。

最终，资源泄漏实际上分为四大类：内存、磁盘、网络和 CPU。无论您是查看应用程序代码、Java 或数据库等来宾操作系统，还是核心操作系统，您可以收集的所有指标都是这些项目的子集。

由于监控可能会给系统性能带来开销，工程人员往往会关注顶层统计数据，直到发现问题为止，然后在已识别的资源泄漏类别中为核心和来宾操作系统部署更深层次的监控，以找出问题所在可能的原因。

如果您正在寻找一些轻量级的深度诊断，可以帮助分析回到单元测试和组件组装阶段，然后在整个性能测试工作中使用相同的工具，那么我可以推荐该组织的解决方案，< a href="http://www.rtiperformance.com/" rel="nofollow">http://www.rtiperformance.com/。

James Pulley

主持人：SQAForums Loadrunner|WinRunner、GoogleGroups lr-loadrunner、YahooGroups LoadRunner|Advanced-LoadRunner、LinkedIn LoadRunner（所有者）| LoadRunnerbyTheHour（所有者）

回复收藏 0 原文

~没有更多了~