Java HttpSession中的信息太多

嗨，你觉得这个问题怎么样

在

HttpSession

中，我们确实有太多的信息，因为计算了很多信息，最终需要在请求之间存储一些大型对象图

使用memcache之类的缓存是否合适？或者这与增加JVM的内存相同

人们担心在请求之间将其存储在数据库中。如果我们要买，你会用什么 内存错误

---

谢谢。

的确，

HttpSession

的伸缩性不好，但这主要与集群有关。这是一种方便，但在某种程度上是的，您最好使用memcache、Terracotta或EHCache之类的工具在请求之间（或用户之间）保存数据。

我认为真正的问题是数据的寿命

---

想想HttpSession的这两个特征：

• 在集群中时，容器负责复制HttpSession。这是好的（你不必自己管理），但如果这导致了太多的交流，就性能而言可能是危险的。。。如果您的应用程序不是集群的，请忘记这一点
• HttpSession的寿命可以是几分钟或几小时，即用户保持活动状态时。这非常适合具有该寿命的信息（连接信息、首选项、授权…）。但它不适用于从一个屏幕到下一个屏幕有用的数据，我们称之为瞬态+数据

---

如果您有集群需求，数据库会处理它。但是要小心，你不能在内存中缓存任何东西

存储在数据库中的寿命更长（在会话之间，甚至在重新启动之间是持久的！），因此这个问题甚至是值得的（除非你用内存问题换取性能问题）

我认为这是一种错误的方法，因为数据的寿命预计不会持久

---

瞬态数据 如果数据只对一个请求有用，那么它通常存储在HttpRequest中

但是，如果它用于几个请求（在一个屏幕内的交互，或者在一个屏幕序列（如助手…）内的交互），则HttpRequest太短，无法存储它，但HttpSession太长。数据需要定期清理

而HttpSession中的许多内存问题都与这些数据有关，这些数据是暂时的，但未被清除（完全被遗忘，或者在出现异常时未被清除，或者当用户不遵守常规流程时：点击

返回
，使用以前的书签、在不同菜单上的clic或其他任何内容）

缓存库以获得正确的使用寿命
为了完全避免这种清理工作（并避免出错时内存耗尽的风险），您可以将信息存储在具有正确寿命的数据结构中。由于容器不提供此功能（无论如何它都与应用程序相关），因此您需要使用缓存库（如前面提到的；我们使用EhCache）自己实现此功能

其思想是您有一个技术代码（与一个功能页面无关，但全局实现，例如使用ServletFilter…），确保在不再需要对象之后始终进行清理

您可以使用以下一个（或多个）策略来设计此缓存，以清理缓存。与功能寿命相关的各项政策：


对于仅与一个屏幕相关的数据（但多个请求：重新加载屏幕、Ajax请求…），缓存一次只能存储一个屏幕的数据（对于每个会话），称之为“currentScreenCache”。这保证了，如果用户转到另一个屏幕（即使是以非托管方式），新屏幕将覆盖“currentScreenCache”信息，并且以前的信息可以被垃圾收集

实现思想：每个请求都必须携带其screenId，负责清除缓存的技术代码会检测当前HttpSession id的当前screenId何时与缓存中的screenId不匹配。然后清除或重置缓存中的该项


对于仅在一系列连接屏幕（称为功能模块）中使用的数据，同样适用于模块级别

实现：和以前一样，每个请求都必须携带模块id


对于重新计算成本较高的数据，可以将缓存库配置为存储最后X次计算的数据（之前的数据在不久的将来不太可能有用）。在典型的使用中，定期请求相同的缓存，因此您有许多缓存命中。在密集使用时，会达到X限制且内存不会膨胀，从而防止OutOfMemory错误（以下次重新计算为代价）

实现：缓存库本机支持这一限制因素，还有其他一些


对于仅在几分钟内有效的数据，缓存库可以本机配置为在延迟后丢弃它


。。。更多信息，请参阅缓存库配置以了解其他想法



注意：每个缓存可以是应用程序范围的，或者特定于用户、HttpSession id、公司id或其他功能值…
如果此日期有效，并且可能在HttpSession的整个生命周期内都需要，那么我们应该使用HttpSession，否则缓存？如果此数据无效，我想写的错误：）@blefesd yes，其想法是将数据存储在具有正确寿命的地方。HttpSession的生命周期相当长…：-）