Sling Servlet中@Reference服务设为transient是否合理？

首先直接给结论：把@Reference标注的服务变量设为transient完全合理，且是Sling环境下的标准最佳实践，你的判断非常正确——让被引用的OSGi服务实现Serializable确实不可行。

为什么transient是正确选择？ #

Sling的SlingAllMethodsServlet和SlingSafeMethodsServlet基类确实实现了Serializable，但OSGi服务（比如你用到的SlingSettingsService）的设计初衷是运行时的组件，几乎不会实现Serializable接口：

• 服务本身可能依赖大量其他运行时资源（比如数据库连接、其他服务实例），这些都无法被序列化；
• 强制让服务实现Serializable会破坏OSGi的组件隔离原则，引入不必要的复杂度和潜在bug。

所以给@Reference的变量加上transient，是绕过Java序列化机制对非序列化字段限制的正确方式。

Sling Servlet会在哪些场景下被序列化/反序列化？ #

主要有这几个典型场景：

• 集群会话复制：如果你的Servlet关联了用户会话（比如处理会话绑定的请求），或者你的Sling/AEM集群配置了会话复制策略，容器可能会序列化Servlet实例并同步到集群的其他节点，以保证状态一致性。
• 容器内存回收/优化：当应用服务器内存资源紧张时，会把不活跃的Servlet实例序列化到磁盘（即"钝化"），当有请求进来需要用到该实例时再反序列化加载（即"活化"）。
• 部分服务器的热部署/重启状态恢复：少数应用服务器会在热部署或重启时序列化部分组件状态，之后反序列化恢复，但这种情况在Sling/AEM的OSGi环境中相对少见，因为OSGi本身有完善的组件生命周期管理机制。

transient的服务引用在反序列化后能恢复吗？ #

完全可以，这也是OSGi组件模型的优势之一：
@Reference注解的依赖注入是由OSGi容器（比如Felix、Equinox）负责管理的，和Java的序列化机制无关。当Servlet实例被反序列化后，OSGi容器会重新识别这个组件实例的依赖需求，自动把对应的服务实例注入到transient变量中，不会出现空指针问题。

换句话说，Java序列化只会处理非transient的字段，而OSGi的依赖注入是独立于序列化的，会在实例创建（包括反序列化后的实例）时重新完成注入。

内容的提问来源于stack exchange，提问作者Tobias Barth