Issue 涉及了下面2个子问题，分开来说明如下：

1. 关于 『传递对象 的有效性维持』

发现替换为TransmittableThreadLocal后，使用agent方式。
在多线程场景下，对session的操作会影响到主线程，比如说取不到session，或者session已关闭。

@wuwu20048

• 传递对象（如DB session对象） 的生命周期（维持DB session对象是有效的），会涉及由 2个或多个协作线程的上层业务逻辑。
• TransmittableThreadLocal的功能 是 对象的跨线程传递，或说 异步上下文的传递。
  • 在传递过程中，TransmittableThreadLocal并不一定能 单方面维持 传递对象是有效的。
  • 如果传递对象只是一般的数据对象，只要传递对象的引用在（TransmittableThreadLocal持有）没有GC掉就好，这样的对象可以 不需要业务逻辑 而是通过TransmittableThreadLocal的引用传递 来维持其生命周期。

原因是：

• TransmittableThreadLocal 没有 维持传递对象有效性的业务逻辑。
• 作为底层库 也不应该/期望 耦合『维持传递对象有效』这样的上层业务逻辑。

基于 你提到的『DB session对象』的具体场景 说明如下：

如果 上层业务没有一些逻辑（如延长 DB事务/DB session对象 直到协作的异步线程不再使用）
来维持 传递的DB session对象是有效性的，
那么 在另一个协作线程使用DB session对象时，可能会是 已经关闭 或者 取不到了。

这个情况/问题 与 是否使用TransmittableThreadLocal 无关。
可以想一下，用手写的逻辑 来 跨线程传递 DB session对象，也一样有这样的问题。

2. 关于『传递对象 是否可修改』

请问支持这种场景吗，还是只能使用值传递，还不能对其进行修改操作？

@wuwu20048

• 如果传递是对象引用，是可以修改的。
  • 通过TransmittableThreadLocal.copy方法的重写（overwrite）来定制 传递对象的拷贝行为，缺省传递的是引用。
• 如果业务逻辑 修改了 传递引用的对象，则业务逻辑要注意传递对象的 线程安全问题。

这个说的在 User Guide 文档中有说明：

1. copy方法
   用于定制 任务提交给线程池时 的ThreadLocal值传递到 任务执行时 的拷贝行为，缺省传递的是引用。
   注意：如果跨线程传递了对象引用因为不再有线程封闭，与InheritableThreadLocal.childValue一样，使用者/业务逻辑要注意传递对象的线程安全。

@wuwu20048 看看说明清楚了吗？欢迎继续讨论～