如何使用Java Mission Control定位非CPU维度的最耗时方法？

1. 耗时环节全链路定位 #

• 优先使用async-profiler采集运行数据，可完全解决JMC只有占比无绝对值的问题：启动批处理任务后执行命令./profiler.sh -d 300 -f profile.html <pid>，采集5分钟运行数据生成火焰图，可直接查看每个方法的总耗时、调用次数，同时自动区分CPU耗时、IO等待耗时、锁阻塞耗时三类数据。
• 重点关注火焰图中宽度占比高的调用栈：PreparedStatement.executeQuery、ResultSet.next类栈占比高则为数据库查询瓶颈；SocketInputStream.read类栈占比高则为Socket IO瓶颈；Unsafe.park类栈占比高则为线程阻塞/锁竞争问题；GC相关栈（如ParNew.doCollection）占比高则为垃圾回收瓶颈。

2. 高怀疑点专项验证 #

JDBC查询专项 #

• 开启JDBC执行日志验证实际耗时：在配置中添加logging.level.org.springframework.jdbc.core=DEBUG，输出每条SQL的执行时间以及总调用次数。你观察到的单次方法15~30ms属于正常范围，但如果每批次处理该方法被调用上百次，千万级数据全量运行时总耗时会累加至秒级甚至分钟级。
• 检查JDBC连接的defaultFetchSize配置：不同数据库的默认fetchSize极低（Oracle默认10行，MySQL默认全量拉取），千万级数据场景下会产生大量网络往返。比如Oracle默认fetchSize=10时，拉取100万行数据需要10万次Socket交互，哪怕单次耗时30ms，总耗时也会达到3000秒。

Socket IO专项 #

• 单独采集Socket IO总耗时：使用async-profiler的-e socket参数运行采集，可直接看到所有Socket操作的累计时长，不需要自己统计单次调用的次数和总耗时。

3. 已做优化的补漏检查 #

• 本地分区优化：检查每个分区的数据源连接是否独立，若连接池最大连接数远小于分区数，会导致大量分区线程阻塞等待连接，分区扩容完全失效。
• 提交间隔配置：不要盲目调大提交间隔，提交间隔超过5000时会导致JVM积压大量未持久化的临时对象，触发频繁Full GC反而降低速度。可在Tomcat启动参数添加-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps输出GC日志，若1小时内Full GC次数超过2次，说明内存配置或对象处理逻辑存在问题。
• 内存分配：检查新生代空间占比，批处理场景下大部分都是朝生夕死的临时对象，新生代占比低于总堆内存的1/2时，会导致对象频繁进入老年代触发Full GC，建议调整新生代占比为总堆内存的1/2~2/3。

4. 快速定位方法 #

若暂时不想做全量采集，可直接在Spring Batch的三个核心环节加入耗时统计逻辑：

// 统计Reader耗时
long readerStart = System.currentTimeMillis();
// 原有ItemReader处理逻辑
long readerCost = System.currentTimeMillis() - readerStart;

// 统计Processor耗时
long processorStart = System.currentTimeMillis();
// 原有ItemProcessor处理逻辑
long processorCost = System.currentTimeMillis() - processorStart;

// 统计Writer耗时
long writerStart = System.currentTimeMillis();
// 原有ItemWriter处理逻辑
long writerCost = System.currentTimeMillis() - writerStart;

// 累计统计各环节总耗时、调用次数即可快速定位瓶颈

运行10分钟后统计三个环节的累计耗时占比，即可快速锁定拖慢整体速度的环节。

内容的提问来源于stack exchange，提问作者hamidreza75