JSF 在服务器端保存 UI 组件状态的时间点以及从服务器内存中移除 UI 组件状态信息的确切时间是什么时候？？当应用程序上的登录用户浏览页面时，组件的状态是否会继续在服务器上累积？
我不明白 在服务器上保持 UI 组件状态有什么好处!？ 直接将经过验证/转换的数据传递给托管 bean 还不够吗？我可以或应该尽量避免吗？
如果有数千个并发用户 session ，这不会消耗服务器端的太多内存吗？我有一个应用程序，用户可以在其中发布有关某些主题的博客。这个博客的规模相当大。当有回帖或浏览博客的请求时，会不会把这个大页面数据保存为组件状态的一部分？这样会占用太多内存。这不是一个问题吗？
更新 1:
现在，在使用 JSF 时不再需要保存状态。可以使用高性能的无状态 JSF 实现。看到这个blog & this question有关详细信息和讨论。此外，还有一个开放的 issue包括在 JSF 规范中，为 JSF 提供无状态模式的选项。 (P.S. 如果这对您有用，请考虑为 this 和 this 问题投票。)
更新 2 (24-02-2013):
Mojarra 2.1.19 推出无状态模式的好消息!
看这里:
http://weblogs.java.net/blog/mriem/archive/2013/02/08/jsf-going-stateless?force=255
最佳答案
Why does JSF need to save the state of UI components on the server side ?
因为 HTTP 是无状态的，而 JSF 是有状态的。 JSF 组件树会受到动态(编程)更改的影响。 JSF 只需要知道表单显示给最终用户时的确切状态，这样它就可以在表单提交回时根据原始 JSF 组件树提供的信息成功处理整个 JSF 生命周期服务器。组件树提供有关请求参数名称、必要的转换器/validator 、绑定(bind)的托管 bean 属性和操作方法的信息。
Until what point in time does JSF save the state of UI components on the server side and when exactly is the UI component's state information removed from the server memory?
这两个问题似乎可以归结为同一个问题。无论如何，这是特定于实现的，并且还取决于状态是保存在服务器上还是客户端上。当它过期或队列已满时，一个有点体面的实现将删除它。例如，当状态保存设置为 session 时，Mojarra 的默认限制为 15 个逻辑 View 。这可以使用 web.xml 中的以下上下文参数进行配置:
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>15</param-value>
</context-param>
另见 Mojarra FAQ对于其他特定于 Mojarra 的参数和此相关答案 com.sun.faces.numberOfViewsInSession vs com.sun.faces.numberOfLogicalViews
As a logged-in user on the application navigates though pages, will the state of components keep on accumulating on the server?
从技术上讲，这取决于实现。如果您谈论的是逐页导航(只是 GET 请求)，那么 Mojarra 不会在 session 中保存任何内容。但是，如果它们是 POST 请求(带有命令链接/按钮的表单)，那么 Mojarra 将保存 session 中每个表单的状态，直到达到最大限制。这使最终用户能够在同一 session 中的不同浏览器选项卡中打开多个表单。
或者，当状态保存设置为客户端时，JSF 不会在 session 中存储任何内容。您可以通过 web.xml 中的以下上下文参数来做到这一点。 :
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
然后它将被序列化为隐藏输入字段中的加密字符串，名称为 javax.faces.ViewState的形式。
I dont understand what the benefit of keeping the UI component's state on the server side is. Isn't directly passing the validated/converted data to managed beans enough? Can/should I try to avoid it?
这还不足以确保 JSF 的完整性和健壮性。 JSF 是一个具有单一控制入口点的动态框架。如果没有状态管理，人们将能够以某种方式欺骗/破解 HTTP 请求(例如，操纵 disabled、readonly 和 rendered 属性)，让 JSF 做不同的 - 并且可能是危险的 - 事情。它甚至容易受到 CSRF 攻击和网络钓鱼。
And won't that consume too much memory on the server side, if there are thousands of concurrent user sessions? I have an application where users can post blogs on certain topics. This blogs are quite large in size. When there will be post back or request for viewing the blogs, the large blogs will be saved as a part of the state of components. This would consume too much memory. Isn't this a concern?
内存特别便宜。只需给应用服务器足够的内存。或者，如果网络带宽对您来说更便宜，只需将状态保存切换到客户端。要找到最佳匹配，只需使用预期的最大并发用户数对您的 web 应用进行压力测试和分析，然后为应用服务器提供 125% ~ 150% 的最大测量内存。
请注意，JSF 2.0 在状态管理方面有了很大改进。可以保存部分状态(例如只有 <h:form> 将被保存，而不是从 <html> 一直保存到最后的全部内容)。例如，Mojarra 就是这样做的。具有 10 个输入字段(每个字段带有标签和消息)和 2 个按钮的平均表单占用的空间不超过 1KB。 session 中有 15 个 View ，每个 session 不应超过 15KB。对于大约 1000 个并发用户 session ，应该不超过 15MB。
您应该更关注 session 或应用程序范围内的真实对象(托管 bean 和/甚至数据库实体)。我见过很多代码和项目，它们不必要地将整个数据库表复制到 Java 的内存中，以使用 Java 而不是 SQL 来过滤/分组/排列记录的 session 范围 bean。对于大约 1000 条记录，每个用户 session 很容易超过 10MB。
关于java - 为什么 JSF 将 UI 组件的状态保存在服务器上？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5474316/