# 1. 问题目前我们有一个系统需要执行大量数据的重算，我们会依据指定条件从数据库中提取入参数据，并使用这些数据进行业务计算。由于数据量巨大，每次都会有将几千万级别的数据，单台机器执行耗时较长，不能满足业务的需求。为了提升执行的速度，我们引入xxljob，将庞大数据量分摊到多台机器执行来缩减总体执行时间。大致流程图如下： ![测算流程图.png](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/507993b0a08843d5a78fc9c0c9d5b084~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg6LSn5ouJ5ouJ5oqA5pyv:q75.awebp?rk3s=f64ab15b&x-expires=1765328882&x-signature=Z8MvLeMQNn1BXPSHlZfXQ39u2UM%3D) 整体任务的执行逻辑如下： * 通过 **xxl-job** 向多台机器分发任务，携带总的数据 ID 区间。 * 每台机器收到任务后，使用统一算法对总区间进行划分，仅处理其负责的子区间。例如： | 机器编号 | 数据区间 | | ---- | ---------- | | 机器 A | 0 \~ 20w | | 机器 B | 20w \~ 40w | | ... | ... | 但是最近一段时间，系统开始偶发出现以下异常情况： * 实际执行完成的数据量少于预期 * 刚刚发布的几天内不会失败，执行一段时间后会失败，重启后能执行成功，再执行一段时间后还是会失败 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/522eb6e2c5de4402a76e51278195e43f~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg6LSn5ouJ5ouJ5oqA5pyv:q75.awebp?rk3s=f64ab15b&x-expires=1765328882&x-signature=ffiGUgKYNvkcr8UloZJN1QMUl70%3D) ## 1.1 排查思路针对这一问题，我们按照常规思路进行了逐一排查 1. **基础设施/部署环境排查** CPU 负载、内存是否过高，IO读写是否报错，网络是否抖动等。 2. **系统层排查** 缓存是否污染，线程池是否阻塞，JVM相关指标是否正常 3. **调度层排查** xxljob轮询是否均衡，是否有调度失败的情况，机器是否频繁上下线或心跳丢失，调度参数是否有误， xxl-job 日志是否有异常等 4. **应用层排查** 日志是否有异常，错误链路追踪等 ## 1.2 问题分析使用上述手段排查之后，仍然无法定位原因，只能在执行过程中加入大量日志，几乎覆盖过程的每一步。最终在日志中发现一些端倪： ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/f2c439905a8a4b4598f03d6a2c717d50~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg6LSn5ouJ5ouJ5oqA5pyv:q75.awebp?rk3s=f64ab15b&x-expires=1765328882&x-signature=vZThCh1SPpLtXHfCzl1FPwu%2BRNc%3D) 结合我们的业务代码 @HllXxlJob(value = "DivideTaskJob") public void DivideTaskJob() { log.info("originParam:{}", HllXxlJobManager.getJobParam()); handleExecutor.execute(() -> { try { String command = HllXxlJobManager.getJobParam() ; log.info("divideParam:{}", HllXxlJobManager.getJobParam()); ...... ParamDTO param = JSONUtils.parseJson(command, ParamDTO.class); Long taskId = param.getTaskId(); Long minId = param.getMinId(); Long maxId = param.getMaxId(); ...... } catch (Exception e) { log.error("IndependentDemandJobHandler.executeIndependentDemandDivideTaskJob error", e); } }); } 根据日志可以看出，部分机器（如图pod1和pod8）执行过程中，第3行获取的参数是 `{"taskId":4111, "minId":20000001, "maxId":"41000000"}`，但是第7行获取的参数却是 `{"taskId":4110, "minId":0, "maxId":"20000000"}` 我们需要执行的taskId是4111，而最终在执行前拿到的taskId却是4110，那执行出来的结果总数肯定对不上。 **那为什么会发生这样的问题呢？** 我们深入xxljob提供的HllXxlJobManager.*getJobParam*()一探究竟 # 2. 源码分析 ## 2.1 xxljob消费端参数获取看看这个方法具体的执行过程 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/1cea2ba1666d49e8af25cb88c8cc2265~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg6LSn5ouJ5ouJ5oqA5pyv:q75.awebp?rk3s=f64ab15b&x-expires=1765328882&x-signature=aeBVo8mTUfHhrkv64r2rQlDQypc%3D) 目前逻辑还比较简单，我们继续深挖参数是如何写入的 ## 2.2 xxljob消费端参数写入 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/3d172653b4b84a00b89ed100979f41c4~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg6LSn5ouJ5ouJ5oqA5pyv:q75.awebp?rk3s=f64ab15b&x-expires=1765328882&x-signature=RzkU%2B8AkCrQYxtjsXMHH0ccpztU%3D) 这里可以看出参数被写入了一个**InheritableThreadLocal，** 那xxljob为什么会使用它呢？他有什么特性呢？ ## 2.3 InheritableThreadLocal特性 InheritableThreadLocal是ThreadLocal的一个子类，它在ThreadLocal的基础上增加了线程间变量继承的功能。当一个线程创建子线程时，子线程会自动继承父线程中所有可继承的InheritableThreadLocal变量的初始值。 **继承性:** * 子线程在创建时，会自动继承父线程中inheritableThreadLocals 中保存的 ThreadLocal 变量的副本。 **初始值:** * 子线程的InheritableThreadLocal变量初始值与父线程相同，但可以在子线程中修改，且不会影响到父线程。介于对xxljob源码分分析，大致调用的结构父线程（Job执行线程） │ ├── 设置 InheritableThreadLocal │ └── 创建子线程（new Thread()） └── 自动继承 XxlJobContext └── 子线程中仍可调用 XxlJobHelper.getJobParam() 所以xxljob的子线程为了获取到job执行线程（父线程）的参数，xxljob设计使用了InheritableThreadLocal ## 2.4 InheritableThreadLocal源码及特性解析 **InheritableThreadLocal源码：** public class InheritableThreadLocal extends ThreadLocal { protected T childValue(T parentValue) { return parentValue; } ThreadLocalMap getMap(Thread t) { return t.inheritableThreadLocals; } void createMap(Thread t, T firstValue) { t.inheritableThreadLocals = new ThreadLocalMap(this, firstValue); } } 我们看到InheritableThreadLocal 继承了 ThreadLocal 类。并且重写了父类的 createMap，getMap ，childValue三个方法。在createMap 和getMap 方法中我们可以看到，将ThreadLocal 方法中的线程threadLocals 属性换成了 inheritableThreadLocals 属性。我们可以看下Thread类中的这成员定义。 public class Thread implements Runnable { ThreadLocal.ThreadLocalMap threadLocals = null; ThreadLocal.ThreadLocalMap inheritableThreadLocals = null; } 我们接着去看设置这些变量的代码 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/37020143fd8144d882e31a78f3ff5e10~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg6LSn5ouJ5ouJ5oqA5pyv:q75.awebp?rk3s=f64ab15b&x-expires=1765328882&x-signature=XbSG%2Bvwp8ulf3aTfvflFtZpUtn0%3D) 再看下ThreadLocalMap(parentMap)构造函数 private ThreadLocalMap(ThreadLocalMap parentMap) { Entry[] parentTable = parentMap.table; int len = parentTable.length; setThreshold(len); table = new Entry[len]; for (int j = 0; j < len; j++) { Entry e = parentTable[j]; if (e != null) { @SuppressWarnings("unchecked") ThreadLocal