1

我的代码正在执行以下操作（仅作为示例，我指定 java.lang.ref.SoftReference 的包路径的原因是要注意它不是我自己的实现:-)：

...
List<String> someData = new ArrayList<String>();
someData.add("Value1");
someData.add("Value2");
...
java.lang.ref.SoftReference softRef = new SoftReference(someData);
...
HttpSession session = request.getSession(true);
session.setAttribute("mySoftRefData", softRef);
...

然后：

...
java.lang.ref.SoftReference softRef = session.getAttribute("mySoftRefData");
if (softRef != null && softRef.get() != null) {
   List<String> someData = (List<String>)softRef.get();
   // do something with it.
}
...

有什么缺点吗？哪个我没看到？谢谢！

4

3 回答 3

1

明显的缺点是列表可能会意外消失。由于会话在过期后会被垃圾收集，因此我并没有真正看到 SoftReference 的用例。如果列表变得相当大（至少足以证明使用 SoftReference 的合理性），我宁愿建议不同的存储（数据库、临时文件）。

于 2010-03-16T23:44:26.470 回答
1

如果您自己没有在代码的其他任何地方引用它，并且 JVM 已经运行了垃圾收集器，那么您可能会冒着引用不再出现在会话中的风险。然而，机会很小，比使用弱参考时要少，但它仍然存在。

我不会在 web 应用程序中这样做。如果是纯会话范围的数据（例如登录用户、购物车等），则只需将其按正常方式放入会话范围即可。如果会话过期或失效，那么任何其他地方都没有引用的东西将以任何方式被垃圾收集。会话范围不打算充当“软”缓存。或者如果它实际上是请求范围的数据，那么宁愿将其存储在请求范围中。否则使用另一种数据存储。

于 2010-03-16T23:45:05.020 回答
0

将应用程序并非 100% 需要的数据放入一次性缓存中是一个非常好的主意。在高峰时段，它们将被丢弃，从而为更紧迫的需求节省更多资源。

简而言之，要走的路。

于 2010-03-16T23:44:46.503 回答