New Project on sonatype:
https://issues.sonatype.org/browse/OSSRH-7596

Position in maven repo:
http://central.maven.org/maven2/com/alibaba/multithread.context

release console:
https://oss.sonatype.org/index.html

PS:

• Sonatype OSS Maven Repository Usage Guide
• Github项目发布到Maven Central

以解决MTC可能失效的问题

@ http://mtc.59504.x6.nabble.com

添加了javassist的jar到bootstrapt classloader中，会让应用的javassist的依赖不能生效。

可以通过repackage javassist来规避

https://github.com/alibaba/transmittable-thread-local/blob/master/docs/requirement-scenario.md

方便用户直接引用以规避bootstrap classpath上的依赖冲突问题。

可以使用maven的sharding插件完成依赖生成

com.alibaba.mtc.MtContextThreadLocal#addMtContextThreadLocal和com.alibaba.mtc.MtContextThreadLocal#removeMtContextThreadLocal方法，目前的时间复杂度是O(n)，n是MtContextThreadLocal的实例个数。

0.9.2修改依赖时，误改了。

如

• 使用Timer
• 继承ThredPool，覆盖了execute方法

用Github pages即可

1. 恢复子时没有处理子中多余Key的情况，结果是：
   子比父多的MtContext被保留在留在子中。
2. 设置子时没有处理子中多余Key的情况，结果是：
   在运行子时，有比父多多的Context！

上面2点合起来，结果是：
在子运行中多出来的Key，被一直保留了。

这打破了MtContext执行时独立的上下文的效果。

POM requirements: Central Sync Requirement

User can override callback method when need prepare biz something before/after task object execute.

See #49

Agent的使用方式，Jar要加到Boot ClassPath上（-Xbootclasspath/a:）
所以依赖一定要精简。

改成JDK的Log：java.util.logging.Logger

• 提供TimerTask的MtContext的Wrapper
• Agent方式修改TimerTask类

以解决MTC可能失效的问题

Hi～

注意到multiple-thread-context提供了上下文线程变量的传递，并提供了针对Runnable及Callable的支持。由于上述场景中有一部分是用在日志中，当前log4j(2)提供了MDC的支持。

想问的是，能否提供一个针对其的增强支持，以log4j2为例已经提供了入口操作的类ThreadContext，若在Executor中传递则需要 使用 该类中的 getContext() and cloneStack() 方法。

此外，框架是否考虑了如何清除这些线程安全变量（以WEB为例大多数是在filter里面使用PUT然后 执行完毕后 POP 或 CLEAR）——是否有好的建议（以multi-thread-context的使用为例）。

在agent修饰jdk线程池中，TTL的修饰执行情况，要看的是

对于线程池不同的使用方式，有没有多次冗余的TTL的修饰。

设计/使用 的 思考分享。

User Guide

• #128 ❤️
• API风格调整成 ThreadLocal使用方式 的设计原因（v0.10.0做的调整） ❤️
• ThreadLocal的内存泄漏安全&线程安全分析 ❤️
• #40
• #55
• #64
• #22
• #4 ❤️
  • #57

Dev Guide

• cancelled #93
• #42 ❤️
• #61
• #24
• #41 ❤️
• Agent
  • #37
  • #5
  • #9
  • #13 ❤️

And...

• #58 🔥

避免与再有应用的兼容性问题

commit: 6888411

主要是清晰地说明MTC使用方式，图比文字更直观：

把 任务提交给线程池时的上下文传递到 任务执行时。

通过com.alibaba.mtc.MtContextThreadLocal#mtContextThreadLocalHolder（ThreadLocal类型）来持有MtContextThreadLocal，是通过WeakReference来持有的。

• 压力测试
• 内存溢出
• TPS

调用com.alibaba.mtc.MtContextRunnable#get、com.alibaba.mtc.MtContextCallable#get方法的意图是保存的是方法调用时的线程上下文。

这样方法如果幂等，则实际效果是之前生成的MtContextRunnable、MtContextCallable时所保存的上下文。即抓取的上下文是错的。

如果传入的MtContextRunnable、MtContextCallable应该 FastFail！实现上可以抛出IllegalStateException异常。

看了javassist的代码有用类名反射的代码，而repackage改变了类名

https://coveralls.io/r/alibaba/multi-thread-context

使用方式由：

// 静态方式，设置和读取配置 
MtContext.set("key", "value");
MtContext.get("key");

改成：

// 一个对象维护一个对象
static MtContext = new MtContext() {
        @Override
        protected MtContext initialValue() {
            return new FooInfo();
        }

        @Override
        protected MtContext childValue(FooInfo parentValue) {
            return new FooInfo(parentValue);
        }
}

这样API的好处：

• 不需要接管对象的创建，这样不需要提供Copyable接口。更友好。
• 不需要检查调用线程，只能是当前线程 #6 。更安全。

与ThreadLocal对比：

• TPS
• 内存泄漏情况说明

这样可以避免 Agent插入的TTL逻辑不被丢掉

如果用户也有Agent，这样可以减少Java参数上Agent参数的个数，简化Agent匹配。