seam依靠SeamListener监听器完成seam的初始化工作
维护seam状态的是一个Contexts类
Contexts内部维护着servlet容器的内置对象以及seam自己的状态内容

在servlet容器启动时，监听器（主线程）完成以下工作：
//将Lifecycle.application.servletContext指向ServletContext
//调用Scanner（实际上是URLScanner）扫描（寻找组件，这里使用了策略模式），在配置文件中寻找组件，并将结果维持在Initialization.componentDescriptors中（Initialization.create()和Initialization.init()）
//Initialization.init()中的ServletLifecycle.beginInitialization()语句将Contexts.applicationContext维护的对象指向ServletContext
//Initialization.init()中的installComponents(init)语句将 Initialization.componentDescriptors中的组件以Component（包装了状态）对象形式存储在 Contexts.applicationContext维护的对象中（其实就是ServletContext的内存地址）
//清理Contexts状态
这样组件就保存在了ServletContext中

在session创建时，监听器（请求线程）完成以下工作：
//从ServletContext中（涉及到Lifecycle.application.servletContext和 Contexts.applicationContext维护的对象）将ScopeType.Sission范围的组件安装到HttpSession
//清理Contexts状态
这样组件就保存在了HttpSession中

seam的jsf生命周期监听器（请求线程）这样工作：
//将Contexts内部对象指向相应servlet内置对象（对话实际上由ConversationEntries.instance()维护，这里我不确定，以后再补上）。
//Contexts内部对象中取组件，如果为空，通过Contexts.applicationContext维护的对象中的Component创建组件。

说得比较粗糙，可能对粗略读过seam源代码的人有点用吧

补充：seam对话上下文也保存在HttpSession中，其以带有对话特有前缀的key作为区别，并由conversationContext.unflush()，conversationContext.flush()等方法维护。

关于线程的部分希望我没说错

说的很详细，学习了，谢谢！