JSP Struts 性能/内存技巧

Question

我正在开发一个基于 Struts 的基本应用程序，该应用程序在内存中会出现重大峰值。我们有一个监控工具，它会注意到每个用户的一个请求会增加 3MB 到 JVM 堆内存。是否有任何提示可以鼓励早期进行垃圾收集、释放内存或提高性能？

该应用程序是一个基本的 Struts 应用程序，但 JSP 报告中有很多行，因此可能创建了很多对象。但它不是你以前没见过的东西。

1. 执行一组数据库查询。
2. 创建一个序列化的 POJO 对象 bean。这代表一行。
3. 向数组列表中添加一行。
4. 在调用操作时将数组列表设置为表单对象。
5. JSP 逻辑将从 ActionForm 遍历列表并将数据显示给用户。

注意事项：
1. 表单在会话范围内，并且可能是数据数组列表（也许这是一个问题）。
2. POJO bean 包含 20 个左右的字段，混合了 String 或 BigDecimal 数据。

报告可以有 300 到 1200 左右的行。所以至少创建了那么多对象。

Answer 1

根据您提供的信息，我估计您通常会为结果加载 1 到 2 兆字节的数据：750 行 * 20 个字段 * 每个字段 100 个字节 = 1.4 Mb。现在考虑数据库和最终标记之间所需的所有临时对象。 3 Mb 不足为奇。

我只担心该内存似乎已泄漏；也就是说，年轻代空间的下一次垃圾回收不会收集所有这些对象。

Answer 2

1. 列表项

在设计要在 Web 应用程序中呈现的报告时，请考虑从数据库中获取的记录数。

如果记录数较多且整个记录集占用大量内存，则考虑使用报表分页。

尽可能不要显式调用垃圾收集器。之所以如此，有两个原因：

1. 垃圾收集是一个昂贵的过程 因为它会扫描整个内存。

2. 大多数生产服务器会 在 JVM 级别进行调整以避免 显式垃圾收集

Answer 3

我认为问题在于 ActionForm 中的数组列表需要分配大量内存空间。我会将查询结果直接写入响应：从结果集中读取行，写入响应，读取下一行，写入等。也许它不是 MVC，但它对你的堆会更好:-)

ActionForms 适用于 CRUD 操作，但对于报告...我不这么认为。

注意：如果 ActionForm 的 scope=session 实例将是活动的（连同巨大的数组列表），直到会话过期。如果 scope=request 实例将可用于 GC。