transmittablethreadlocal 的确是个容易掉坑的地方。它旨在解决 threadlocal 在线程池场景下值无法传递的问题，听起来很美好，但实际应用中却常常出现意想不到的麻烦。
我曾经在一个大型项目中使用 TransmittableThreadLocal 来传递用户身份信息，一开始一切顺利，直到线上出现一个诡异的 bug：部分用户的请求数据错乱，用户的身份信息与实际操作不符。经过一番排查，最终发现问题根源在于我们对 TransmittableThreadLocal 的使用方法存在误解。
我们当时错误地认为，只要使用了 TransmittableThreadLocal，就能保证在任何情况下都能正确传递值。但实际上，它并非万能的。 它的机制依赖于对线程池的改造，如果你的线程池没有正确集成或配置，或者使用了不支持它的框架，TransmittableThreadLocal 就无法正常工作。 我们的问题就出在这里：我们使用了第三方库提供的自定义线程池，而这个线程池并未与 TransmittableThreadLocal 兼容。
解决这个问题的过程也并非一帆风顺。我们尝试了多种方法，包括修改第三方库的源码（这风险很大，不推荐），更换线程池实现，以及调整代码逻辑以避免依赖 TransmittableThreadLocal。最终，我们选择了一种折衷方案：在自定义线程池的 beforeExecute 方法中手动复制 ThreadLocal 的值。这虽然增加了代码复杂度，但保证了稳定性，并避免了修改底层库的风险。
另一个需要注意的地方是，TransmittableThreadLocal 的值复制是浅拷贝。这意味着，如果你的 ThreadLocal 中存储的是可变对象，那么在不同的线程中修改这个对象，会影响到所有线程。 我曾经因为这个原因，导致多个用户的数据相互污染。解决方法是，确保 ThreadLocal 中存储的是不可变对象，或者在复制值时进行深拷贝。
所以，使用 TransmittableThreadLocal 需要谨慎。在使用之前，务必确认你的线程池支持它，并且理解其浅拷贝的特性。 如果条件不允许，或者风险过高，不妨考虑其他方案，例如使用请求上下文，或者在方法参数中显式传递需要共享的数据。 与其盲目依赖它，不如仔细权衡利弊，选择最适合你项目情况的方案。 记住，代码的稳定性和可维护性比使用新技术的诱惑更重要。 避免因为追求所谓的“优雅”而引入新的隐患。
