我们遇到了异常高的内存使用问题。我观察到在我们的代码中的许多地方，我们从数据库中提取了 100 条记录，将其打包到自定义数据对象中，将其添加到数组列表中并存储在会话中。我想知道在会话中存储数据的推荐上限是多少。只是一种好的做法，不好的做法。
我正在使用 JRockit 1.5 和 1.6GB 的 RAM。我使用 Jprobe 进行了分析，发现应用程序的某些部分具有非常大的内存占用。大部分数据都将进入会话以供以后使用。
【问题讨论】：
标签： java session memory-management
这完全取决于通常存在多少会话（这又取决于您拥有多少用户、他们在网站上停留的时间以及会话超时）以及您的服务器有多少 RAM。
但首先：您是否真的使用了内存分析器来告诉您“高内存使用”是由会话数据引起的，还是您只是在猜测？
如果您遇到的唯一问题是生产机器上的“高内存使用率”（即它可以处理生产负载但性能不如您所愿），那么最简单的解决方案是为服务器 - 比重新设计应用程序更快、更便宜。
但是在会话中缓存整个结果集也有不同的原因：如果数据库中的数据发生变化并且用户希望看到这种变化怎么办？如果您要缓存，请使用在 DB 请求级别执行此操作的 one of the existing systems - 他们将允许您在用户之间缓存结果，并且他们有缓存失效的设施。
【讨论】：
如果您将数据存储在会话中以提高性能，请考虑使用真正的缓存，因为缓存是应用程序范围的，而会话是每个用户的，这会导致不必要地重复其他类似对象。
但是，如果您要存储它们以供用户编辑这些对象（我对此表示怀疑，因为数百个对象太多了），请尝试最小化存储的数据量或研究乐观并发控制。
【讨论】：
我想说这在很大程度上取决于您期望的活动会话数。如果您正在编写一个少于 20 个用户的 Intranet 应用程序，那么在会话中放入几 MB 肯定没有问题。但是，例如，如果您期望 5000 个实时会话，则每个会话存储的每 MB 数据占用 5GB 的 RAM。
但是，我通常建议不要在会话中存储数据库中的任何数据。只需从数据库中获取每个请求。如果性能有问题，请使用应用程序范围的缓存（例如 Hibernate 的二级缓存）。
【讨论】：
它是什么种类的数据？每个会话真的需要它还是可以在应用程序级别缓存？你真的需要所有的列还是只需要一个子集？它多久被访问一次？它需要在哪些页面上可用？以此类推。
当您真正需要时，从数据库中检索记录可能更有意义。在会话中存储数百条记录绝不是一个好策略。
【讨论】：
我会说尝试存储足以在后续请求中重新创建必要环境的最小数据量。如果您将存储在内存中以避免数据库往返，那么真正的缓存解决方案（例如 Memcache）可能会有所帮助。
如果您将这些会话存储在内存中而不是数据库中，则可以节省往返行程，并且只要内存负载较低且没有分页，请求的处理速度就会更快。一旦客户端数量增加并开始分页，大多数客户端将看到响应时间大幅下降。这两个变量又成反比关系。
最好测量数据库服务器的延迟，在大多数情况下，延迟通常足够低，可以被视为一种可行的存储方式，而不是内存。
【讨论】：
尝试将您当前存储在会话中的数据拆分为特定于用户的数据和静态数据。然后为所有静态部分实现缓存。这将为您提供大量应用程序范围内的重用，并且仍然允许您缓存用户正在处理的特定数据。
【讨论】：
您还可以创建每个用户的迷你 sqlite 数据库并连接到它，并将用户正在访问的数据存储在其中，然后在用户请求它时从中检索记录，并且在用户断开连接之后删除 sqlite 数据库。
【讨论】：