通过书中的摘要，我发现了这个：
在服务器端，状态可以存储为浅拷贝或作为 深刻的副本。在浅拷贝中，状态未在序列化中 会话。默认情况下，JSF Mojarra使用浅拷贝。
我真的不明白这一点。
由于在上述情况下，我们将 -
javax.faces.STATE_SAVING_METHOD设置为server，
和输入隐藏字段javax.faces.ViewState，其值有点像"2870966362946771868:-8449289062699033744"。
显然，服务器必须在内部维护与上述隐藏字段对应的状态。
但是，如果状态没有在会话中序列化，那么它是抽象的，那么它在哪里呢？
此外，我注意到一件事，如果我的托管bean（ViewScoped）没有实现标记接口Serializable，STATE_SAVING_METHOD设置为server，那么在{{ 1}}，Mojarra不会发生，而NotSerializablEexception则会发生。{/ p>
答案 0 :(得分：4)
但是，如果状态未在会话中序列化，那么它是抽象的，那么它在哪里呢？
存在对HTTP会话中已有实例的引用，而这些实例又不一定是序列化的。
关键的上下文参数是javax.faces.SERIALIZE_SERVER_STATE，MyFaces默认为true，Mojarra默认为false。设置为true后，您很快会看到NotSerializableException关于错误地不是Serializable的工件。否则，您依赖于服务器配置。例如，Tomcat默认情况下序列化整个HTTP会话，包括服务器重新启动期间的所有属性。某些服务器，尤其是那些在集群中运行的服务器，甚至可以配置为在运行时序列化整个HTTP会话。在这种情况下，您还会在重新启动或故障转移期间看到NotSerializableException。
Mojarra计划根据2.3将javax.faces.SERIALIZE_SERVER_STATE默认设置为true，特别是因为此设置会主动防止无法预见的开发人员错误，例如分配不可序列化的JSF工件实例，例如{{1 }或甚至UIComponent作为非请求用bean的属性。否则会导致Stuck thread at UIComponent.popComponentFromEL，Java Threads at 100% CPU utilization using richfaces UIDataAdaptorBase and its internal HashMap和java.lang.IllegalStateException at com.sun.faces.context.FacesContextImpl.assertNotReleased出现问题。
另一方面，在较旧的MyFaces版本中，由于在反序列化期间使用了错误的类加载器来解析EJB代理，因此此设置破坏了可序列化托管bean中注入的EJB。根据{{3}}在MyFaces 2.0.15和2.1.9中修复了此问题。另见MyFaces issue 3581。