为什么JSF需要在服务器端保存UI组件的状态？
因为HTTP是无状态的，而JSF是有状态的。JSF组件树会进行动态（编程）更改。JSF仅需要知道表单显示给最终用户时的确切状态，以便当表单提交回给用户时，它可以基于原始JSF组件树提供的信息成功处理整个JSF生命周期。服务器。组件树提供有关请求参数名称，必需的转换器/验证器，绑定的受管bean属性和操作方法的信息。
直到什么时候JSF都将UI组件的状态保存在服务器端，以及何时才将UI组件的状态信息从服务器内存中删除？
这两个问题似乎可以归结为相同的问题。无论如何，这是特定于实现的，并且还取决于状态是保存在服务器还是客户端上。当它已过期或队列已满时，有点体面的实现会将其删除。例如，将状态保存设置为会话时，Mojarra的默认限制为15个逻辑视图。这可以通过以下上下文参数进行配置web.xml：
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>15</param-value>
</context-param>
另请参阅Mojarra常见问题解答以获取其他特定于Mojarra的参数以及相关的答案com.sun.faces.numberOfViewsInSession与com.sun.faces.numberOfLogicalViews
当应用程序上的登录用户浏览页面时，组件的状态是否会继续在服务器上累积？
从技术上讲，这取决于实现方式。如果您正在谈论页面到页面的导航（只是GET请求），那么Mojarra将不会在会话中保存任何内容。但是，如果它们是POST请求（带有命令链接/按钮的表单），则Mojarra将在会话中保存每种表单的状态，直到达到最大限制。这使最终用户可以在同一会话中的不同浏览器选项卡中打开多个表单。
或者，当状态保存设置为客户端时，JSF将不会在会话中存储任何内容。您可以通过以下上下文参数来实现web.xml：
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
然后，它将在隐藏输入字段中使用javax.faces.ViewState表单名称序列化为加密的字符串。
我不明白将UI组件的状态保持在服务器端的好处是什么。将经过验证/转换的数据直接传递到托管bean是否不够？我可以/应该避免吗？
这还不足以确保JSF的完整性和健壮性。JSF是具有单个控件入口点的动态框架。如果没有状态管理，人们将能够欺骗/ HTTP黑客以某种方式请求（如操纵disabled，readonly和rendered属性），让JSF做不同的-和潜在hazardful-事情。甚至可能容易遭受CSRF攻击和网络钓鱼。
如果有成千上万的并发用户会话，那会不会在服务器端消耗太多内存？我有一个应用程序，用户可以在其中发布有关某些主题的博客。这个博客的规模很大。当将有回发或请求查看博客时，大型博客将被保存为组件状态的一部分。这将消耗过多的内存。这不是问题吗？
内存特别便宜。只要给应用服务器足够的内存即可。或者，如果网络带宽对您来说更便宜，则只需将状态保存切换到客户端即可。为了找到最佳匹配，只需对您的Web应用进行压力测试并配置其预期的最大并发用户数，然后为该应用服务器提供125％〜150％的最大测量内存。
注意，JSF 2.0在状态管理方面进行了很多改进。这是可能的节省部分的状态（例如只在<h:form>将被保存，而不是整个东西从<html>一路结束）。例如，Mojarra就是这样做的。一个带有10个输入字段（每个带有标签和消息）和2个按钮的平均表单所占用的空间不超过1KB。在会话中有15个视图时，每个会话的最大访问量不应超过15KB。在大约1000个并发用户会话的情况下，该大小不应超过15MB。
您应该关注的是会话或应用程序范围内的实际对象（托管Bean和/或数据库实体）。我已经看到了许多代码和项目，这些代码和项目不必要地将整个数据库表复制到Java的内存中，而成为会话作用域的bean，其中使用Java而不是SQL来过滤/分组/排列记录。拥有约1000条记录，每个用户会话很容易超过10MB 。