最近，我已经覆盖了Wicket的 DefaultPageStore 方法 serializePage 和 deserializePage ，并通过记录来增强它们以跟踪花费的时间在他们中间。
我发现永远不会调用 deserializePage ，因为实际页面总是从 SessionEntry＃sessionCache 中检索。
我怀疑这是由于我的页面设置 setVersionPagesByDefault（false），这会导致只有当前版本的页面在 SessionEntry 中序列化并且然后（不必要地）在 DefaultPageStore 中，从那里它从未被反序列化。
如果这种怀疑是正确的，我可以使方法 serializePage 成为无操作并跳过序列化，目前需要3或7秒（DeflatedJavaSerializer）用于页面X.
到目前为止我没有发现任何副作用，所以我的问题是： 这样安全吗？如果没有，那么为什么？
我认为这只是暂时的解决方案，直到我能够将数据从页面移动到正确的缓存中。
答案 0 :(得分：1)
以下是有关页面版本控制的一些信息：http://wicket.apache.org/guide/guide/versioningCaching.html
如果您不需要支持后退按钮，则可以禁用页面版本控制 - 它没有副作用，假设您的页面正确处理后退按钮。跳回到没有状态的页面可以创建没有初始参数的页面。例如：您从页面A跳到B并向B提供一些参数。现在用户在页面C上并单击后退按钮。这将导致重定向到页面B，但这次不会传递任何参数。如果您要使用页面版本控制，wicket只会反序列化页面B并再次执行渲染。
这也是禁用页面存储的一种可能性： http://maciej-miklas.blogspot.de/2013/09/wicket-6-disable-page-serialization.html