关于数据库:TiDB-适配应用实践MyBatis-35X-在-JDK8-中性能问题的排查与优化

最近有金融客户应用 TiDB 适配批处理场景，数据量在数亿级。对于雷同的数据量的解决耗时，TiDB 有 35 分钟，Oracle 有 15 分钟，足足相差 20 分钟。从之前的教训来看，在批处理场景上 TiDB 的性能是要好过 Oracle 的，这让咱们感到困惑。通过一番排查最终定位是批处理程序问题。调整后，在应用服务器有性能瓶颈、数据库压力仍然不高且没有进行参数优化的状况下，TiDB 解决工夫缩短到 16 分钟，与 Oracle 简直持平。

近程排查

通过 Grafana 发现执行批处理时数据库集群的资源使用率非常低，判断利用发来的压力较小，将并发数从 40 进步到 100，资源使用率和 QPS 指标简直没有变动。通过 connection count 监控看到，连接数随着并发数减少而减少，确认并发数批改是失效的。执行 show processlist 发现大部分连贯是闲暇状态。简略走查了下利用程序代码，是 Spring batch + MyBatis 构造。因为 Spring batch 设置并发的形式很简略，所以思考线程数的调整应该是失效且能够失常工作的。
尽管还没有搞清资源使用率低的问题，但还是有其余播种，ping 利用和 TiDB 集群的网络提早，达到了 2~3 ms。为了排除高网络提早的烦扰，将利用部署到 TiDB 集群外部运行，批处理耗时从 35 分钟降落到 27 分钟，但仍然和 Oracle 有较大差距。因为数据库自身没有压力，所以调整数据库参数也没什么意义。

因为利用进步并发的成果不合乎预期，所以思考线程可能造成了阻塞，但也没有证据，于是想了这样的场景来简略验证到底是利用的问题还是数据库的问题：
在 TiDB 集群中创立两个完全相同的 Database，d1 和 d2，应用两个完全相同的批处理利用别离对 d1，d2 中的数据进行解决，等同于双倍压力写入 TiDB 集群，预期后果是对于双倍的数据量，同样能够在 27 分钟解决完，同时数据库资源使用率应大于一个利用的。
测试后果合乎预期，证实利用没有真正的进步并发。

可能的起因？

1. 利用并发太高，CPU 忙碌导致利用性能瓶颈。

   应用服务器的 CPU 耗费只有 6%，不应该存在性能瓶颈。

2. Spring batch 外部有一些元数据表，同时更新元数据表的同一条数据会造成阻塞。

   这种状况应该是阻塞在数据库造成锁期待或锁超时，不应该阻塞在利用端。

该如何解决？

1. 多利用部署并发运行，性能随利用部署数线性晋升。

   不能解决单机利用性能瓶颈问题，对于业务顶峰时的拓展也很不不便。

2. 采纳异步解决的计划，进步利用吞吐。

   目前是有些异步拜访数据库的技术，但成熟度低，强烈不倡议应用。

现场排查

为了弄清问题根本原因，来到现场。

• 现场应用 JDBC 编写了一个 Demo 对问题集群进行压测，发现数据库资源使用率随着 demo 并发数进步而增长，证实进步并发数能够给数据库制作更高的压力，此时齐全排除数据库问题的可能。
• 通过 VisualVM 发现，应用程序的大量线程处于阻塞状态，这种状况线程开的多其实也没用上，实锤性能瓶颈来自利用。

• 走查利用代码，发现尽管有用到同步锁等逻辑，但应该不会造成重大的线程阻塞。
• 通过 dump 发现线程都阻塞在了 MyBatis 的堆栈中，是在源码的这个地位：

@Override
  public Reflector findForClass(Class<?> type) {if (classCacheEnabled) {// synchronized (type) removed see issue #461
      return MapUtil.computeIfAbsent(reflectorMap, type, Reflector::new);
    } else {return new Reflector(type);
    }
  }

这里大抵是这样，MyBatis 在进行参数解决、后果映射等操作时，会波及大量的反射操作。Java 中的反射尽管功能强大，然而代码编写起来比较复杂且容易出错，为了简化反射操作的相干代码，MyBatis 提供了专门的反射模块，它对常见的反射操作做了进一步封装，提供了更加简洁不便的反射 API。DefaultReflectorFactory 提供的 findForClass() 会为指定的 Class 创立 Reflector 对象，并将 Reflector 对象缓存到 reflectorMap 中，造成线程阻塞的就在对 reflectorMap 的操作上。

因为 MyBatis 反对对 ReflectorFactory 自定义实现，所以过后的思路是绕过缓存的步骤，也就是将 classCacheEnabled 设为 false，走 return new Reflector(type) 的逻辑。但仍然会在其余调用 ConcurrentHashmap.computeIfAbsent 的中央被阻塞。

到这看起来是一个通用问题，于是将注意力放到 concurrentHashmap 的 computerIfAbsent 上。computerIfAbsent 是 JDK8 中 为 map 提供的新办法

public V computeIfAbsent(K key, Function<? super K,? extends V> mappingFunction)

它首先判断缓存 map 中是否存在指定 key 的值，如果不存在，会主动调用 mappingFunction (key) 计算 key 的 value，而后将 key = value 放入到缓存 Map。ConcurrentHashMap 中重写了 computeIfAbsent 办法确保 mappingFunction 中的操作是线程平安的。

官网阐明中一段：

The entire method invocation is performed atomically, so the function is applied at most once per key. Some attempted update operations on this map by other threads may be blocked while computation is in progress, so the computation should be short and simple, and must not attempt to update any other mappings of this map.

能够看到，为了保障原子性，当对雷同 key 进行批改时，可能造成线程阻塞。不言而喻这会造成比较严重的性能问题，在 Java 官网 Jira，也有用户提到了同样的问题。

[[JDK-8161372] ConcurrentHashMap.computeIfAbsent(k,f) locks bin when k present](https://bugs.openjdk.java.net…

很多开发者认为 computeIfAbsent 是不会造成线程 block 的，事实却相同。Java 官网过后认为这个设计是没问题的，不过之后也感觉在性能还不错的 Concurrenthashmap 中有这么个拉胯兄弟属实不太适合。最终在 JDK9 中修复了这个问题。

验证

将现场 JDK 版本升级到 9，利用在 500 并发，并排除网络提早烦扰的状况下，批处理耗时 16 分钟。应用服务器 CPU 达到 85% 左右使用率，呈现性能瓶颈。实践上，进步应用服务器配置、优化数据库参数都能够进一步晋升性能。

过后的论断

MyBatis 3.5.X 在缓存反射对象用到的 computerIfAbsent 办法在 JDK8 中性能不现实。须要降级 jdk9 及以上版本解决这个问题。对于 MyBatis 3.5.X 自身，没有针对 JDK8 中的 computerIfAbsent 性能问题进行非凡解决。

降级的路走不通，也能够试着降级到 MyBatis 3.4.X，这个版本还没有引入 computerIfAbsent，实践上没有这个问题。

@Override
public Reflector findForClass(Class<?> type) {if (classCacheEnabled) {// synchronized (type) removed see issue #461
      Reflector cached = reflectorMap.get(type);
      if (cached == null) {cached = new Reflector(type);
        reflectorMap.put(type, cached);
      }
      return cached;
    } else {return new Reflector(type);
    }
  }

当初的论断

MyBatis 官网在收到咱们的反馈后，十分效率地 fix 了这个问题。手动点赞。

能够看到 MyBatis 官网对 computerIfAbsent 进行了一层封装，如果 value 已存在，则间接 return，这样操作雷同 key 的线程阻塞问题就被绕过去了。MyBatis 会在 3.5.7 版本中合入这个 PR。

public class MapUtil {
  /**
   * A temporary workaround for Java 8 specific performance issue JDK-8161372 .<br>
   * This class should be removed once we drop Java 8 support.
   *
   * @see <a href="https://bugs.openjdk.java.net/browse/JDK-8161372">https://bugs.openjdk.java.net/browse/JDK-8161372</a>
   */
  public static <K, V> V computeIfAbsent(Map<K, V> map, K key, Function<K, V> mappingFunction) {V value = map.get(key);
    if (value != null) {return value;}
    return map.computeIfAbsent(key, mappingFunction::apply);
  }

  private MapUtil() {super();
  }
}

结语

通过这次排查，咱们发现了 JAVA 语言源代码中的 bug，并且进一步推动了曾经受这个 bug 影响的 MyBatis 框架绕开了这个编程语言级的 bug。调整后的利用处理速度大幅晋升，在咱们这个场景中晋升了一倍以上。置信对于应用利用开发框架 MyBatis 的企业来说会提供微小帮忙。