1. thread -n 500 | grep 'XNIO' -C 100 :::info 查询 前500个耗时的线程 并提取出 线程名为 XNIO 的线程，-C表示每个匹配项都输出100行（否则只会输出一行，就只能看到线程名字，里面的调用栈就看不到了。为什么查询XNIO？因为XNIO是undertow应用服务器的网络框架，咱们的工作线程是跑在这个上面的。 :::

    2. 因为Arthas都是文本信息，所以我们可以把文本存下来，然后在你感觉舒适的文本编辑器里分析，把可疑的类+方法复制下来，替换以下命令中的占位符：monitor -c 30 <全限定类名> <方法名>

      • <全限定类名>，比如 com.rl.mp.component.service.impl.MaterialServiceImpl
      • <方法名>，比如 uploadTempMaterial :::warning 该命令可以作为后台任务执行，方便你可以再去观察其他的方法。使用方法是：
        monitor -c 30 <全限定类名> <方法名> &
        使用jobs可以列出所有后台执行的任务，每个任务会有个ID；使用fg <id>将任务切换到前台使用。
        这里面的avg-rt表示平均响应时长，可以简单理解为这个方法执行耗时。这里表示一个抓取周期内N次方法调用的平均返回耗时，数值越大说明越拉跨。 :::

    3. 在少量耗时严重+大量耗时少的情况下，平均值反应不出来效果。可以使用：

    trace <类名> <方法名> '#cost > <耗时>'
    连续查看一个 执行耗时 大于<耗时>(单位：毫秒) 的方法的执行链路。 :::warning ‘#cost > <耗时>’ 表示过滤条件，过滤 方法执行耗时大于给定值 的执行链路 :::

    最后明天arthas不一定能attach在即将崩溃的JVM上，如果实在不行就多执行几次jstack -l <PID>，执行一次保存一份屏幕输出（把打印缓冲区配大一点），这么做的主要原因是看看大多数工作线程卡在什么环节，方便定位问题。