一、引言
最近有个线上日志丢失tag的问题，是组内封装了后置请求的拦截器把请求的响应结果存到ClickHouse里面去，但是日志总有一些tag丢失。
作者提出父级线程的threadlocal被清空，同事认为可能是threadlocal的弱引用在gc的时候被回收。两种想法其实都是有可能的，那就要一个个验证。这里要感谢ld和cbc的共同排查、讨论，最后锁定原因是父级线程的MDC被ar组件清空。
二、问题
1、架构背景
这里先讲讲问题后面架构的背景，由于需要按照特定的格式存一些日志数据到ck，组内封装的后置拦截器会使用slf4j的MDC.getCopyOfContextMap()获取请求被存储在ThreadLocal里面的map，里面放了一些订单、人员信息的key-value，拿到这些数据再和一些响应参数存入ck。
集团的日志框架里面实现了servlet的Filter，在servlet容器初始化的时候会运行这个拦截器，把一部分埋点运行，但是会清空，保证进入业务处理的时候是干净的。真正用到的买点是在业务线程里面实现的，所以在业务处理完成到后置拦截器的过程中可能存在clear的操作。需要把框架整体结构研究下。
2、问题背景
在落数据的监控，看到有几列偶现是空的。
看代码确认这些空列都是从MDC取出来的。
三、分析
快速的讨论锁定了出问题的代码。
1、代码
这个代码是从父线程取出来日志信息，作为入参返回给子runnable，等到子runnable启动的时候，它就变成了子线程里面的threadlocal。
@Override
public void apply(PostResponseFilterArgs args) {
try {
Runnable logTask = () -> doLog(args);
if (CommonLogConfig.logAsync()
&& StringUtilsExt.isNotBlank(CommonLogConfig.logExecutor())) {
TaskRunner.create(LogTagsWrap.wrap(logTask)).start(CommonLogConfig.logExecutor());
} else {
logTask.run();
}
} catch (Throwable e) {
LOGGER.info(TITLE, e);
}
}
public static Runnable wrap(Runnable runnable) {
Map<String, String> logTags = log.getCommonTags();
return () -> {
log.setCommonTags(logTags);
runnable.run();
};
}
private static void doLog(PostResponseFilterArgs args) {
// 构建业务信息
Map<String, String> map = LogUtil.buildService(args);
// 设置MDC信息
LogUtil.setMdc(map);
// 记录CK日志
Throwable throwable = args.executionResult().throwable();
if (Objects.nonNull(throwable)) {
LogUtil.error(map, throwable, CommonLogConfig.logScenario());
} else {
LogUtil.info(map, null, CommonLogConfig.logScenario());
}
}
2、浅拷贝✖️
作者一开始以为这里父级线程取出来的可能是浅拷贝，然后在子线程启动之前被其他请求使用了，导致并发清空。但是追溯下去，MDC使用的是深拷贝拿到日志信息。
@Override
public Map<String, String> getCopy() {
final StringMap map = localMap.get();
return map == null ? new HashMap<>() : map.toMap();
}
@Override
public Map<String, String> getCopy() {
final Map<String, String> map = localMap.get();
return map == null ? new HashMap<>() : new HashMap<>(map);
}
public HashMap(Map<? extends K, ? extends V> m) {
this.loadFactor = DEFAULT_LOAD_FACTOR;
putMapEntries(m, false);
}
final void putMapEntries(Map<? extends K, ? extends V> m, boolean evict) {
int s = m.size();
if (s > 0) {
if (table == null) { // pre-size
float ft = ((float)s / loadFactor) + 1.0F;
int t = ((ft < (float)MAXIMUM_CAPACITY) ?
(int)ft : MAXIMUM_CAPACITY);
if (t > threshold)
threshold = tableSizeFor(t);
}
else if (s > threshold)
resize();
for (Map.Entry<? extends K, ? extends V> e : m.entrySet()) {
K key = e.getKey();
V value = e.getValue();
putVal(hash(key), key, value, false, evict);
}
}
}
3、子级threadlocal在gc时回收✖️
不过子线程里面一定是在set mdc信息的时候是空的，也就引出来开头作者和同事的两个猜想。threallocal作者感觉是不太可能的，因为线程执行完才算是强引用链结束，但是还是写个测试方法试一试。
使用system.gc强制回收，看看会不会把threadlocal给回收，结果并没有。这里要设置启动参数，不然system.gc不一定会执行。
public static void main(String[] args) {
List<Task> list = new ArrayList<>();
for (int i = 0; i < 10000;i++) {
System.out.println(i + "start");
Map<String, String> md = new HashMap<>();
md.put("orderid",i + "666");
// 设置MDC信息
MDC.setContextMap(md);
int finalI = i;
Runnable logTask = () -> {
// 构建SOA信息
Map<String, String> map = new HashMap<>();
map.put("soa", finalI + "666");
System.gc();
// 设置MDC信息
LogUtil.setMdc(map);
System.out.println(map);
if (map.size() == 1) {
System.out.println(finalI + "soaerror");
}
};
Task t = TaskRunner.create(LogTagsWrap.wrap(logTask));
list.add(t);
System.out.println(i + "end");
}
for (Task t : list) {
t.start(CommonLogConfig.logExecutor());
}
}
4、父级MDC信息清空☑️
那么接下来就是看会不会清空父级线程的threadlocal了，作者把框架整体看了一遍。感觉出问题的地方还不少，就看这些拦截器是不是会异步走清理。
cbc使用过arthas进行线上诊断，作者也学习了一波，使用watch对全限定名的类方法进行字节码动态生成，打印方法的出入参便于排查。
但是作者这里的情况比较特殊，由于需要确定父级丢失还是子级的gc回收，需要在两个方法里面取出MDC的log信息，在为空的时候打印出来。作者和cbc折腾了许久，比较复杂的监控arthas还是不好用的。就在这时候ld给出了新的方向。
5、ar组件清空父级MDC信息☑️
他发现出问题的机器ip固定在某两台机器上面，于是我们开始分析这两天机器与其他机器有什么不同。cbc之前接触过测开组做了一个ar组件，使用java-agengt方法在服务发布时注入，这是我们观察不到但是有可能进行拦截增强的代码。
于是我们开始研究他的源码，果然这个组件使用了 SerivceInstrumentation extends TypeInstrumentation类进行字节码增强，并且是在业务处理的方法外层进行增强，比后置拦截器早。
@Override
protected ElementMatcher<TypeDescription> typeMatcher() {
return named("server.OperationHandler");
}
private static void recordMocker(Mocker mocker) {
// 业务处理
MDC.clear();
}
他的过程可以画成这样。
关掉ar组件之后，可以看到没有再发生有问题的ck日志记录，了解到ar组件的执行频率是一小时10次，这也说明了为什么我们发现的监控是部份发生，其实这个组件导致了必然的结果。
一切的偶然总有必然的原因！
四、总结
再次抒感：一切的偶然总有必然的原因！这次的问题告诉了我们，问题不一定出现在看得见的代码，java-ageng之类看不见的代码很多时候是另外一个方向。
这里再次感谢ld和cbc的协作分析，合作无间！