为什么 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 vs 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，让 JSF 做不同的——并且可能是危险的——事情。它甚至容易受到 CSRF 攻击和网络钓鱼。readonlyrendered
如果有数千个并发用户会话，这不会在服务器端消耗太多内存吗？我有一个应用程序，用户可以在其中发布有关某些主题的博客。这个博客的规模相当大。当有回帖或查看博客的请求时，大型博客将被保存为组件状态的一部分。这会消耗太多内存。这不是一个问题吗？
内存特别便宜。只需给应用服务器足够的内存。或者，如果网络带宽对您来说更便宜，只需将状态保存切换到客户端。要找到最佳匹配，只需使用预期的最大并发用户数对您的 web 应用程序进行压力测试和分析，然后给应用程序服务器 125% ~ 150% 的最大测量内存。
请注意，JSF 2.0 在状态管理方面有了很大改进。可以保存部分状态（例如，只有将<h:form>被保存而不是从<html>一直到结束的全部内容）。例如，Mojarra 就是这样做的。具有 10 个输入字段（每个字段带有标签和消息）和 2 个按钮的平均表单占用的空间不超过 1KB。会话中有 15 个视图，每个会话不应超过 15KB。对于约 1000 个并发用户会话，应该不超过 15MB。
您应该更关注会话或应用程序范围内的真实对象（托管 bean 和/甚至数据库实体）。我见过很多代码和项目，它们不必要地将整个数据库表复制到 Java 的内存中，以使用 Java 而不是 SQL 来过滤/分组/排列记录的会话范围 bean。有大约 1000 条记录，每个用户会话很容易超过 10MB 。