Thread 命令可以查看当前线程信息，查看线程的堆栈.
直接使用thread命令将默认按照 CPU 增量时间降序排列，只显示第一页数据。
1 | $ thread |
展示当前最忙的前 N 个线程并打印堆栈：
1 | $ thread -n 3 |
[Internal]表示为 JVM 内部线程，参考dashboard命令的介绍。cpuUsage为采样间隔时间内线程的 CPU 使用率，与dashboard命令的数据一致。deltaTime为采样间隔时间内线程的增量 CPU 时间，小于 1ms 时被取整显示为 0ms。time 线程运行总 CPU 时间。注意：线程栈为第二采样结束时获取，不能表明采样间隔时间内该线程都是在处理相同的任务。建议间隔时间不要太长，可能间隔时间越大越不准确。 可以根据具体情况尝试指定不同的间隔时间，观察输出结果。
显示所有匹配线程信息，有时需要获取全部 JVM 的线程数据进行分析。
1 | $ thread 1 |
有时候我们发现应用卡住了， 通常是由于某个线程拿住了某个锁， 并且其他线程都在等待这把锁造成的。 为了排查这类问题，可以通过thread -b命令 一键找出罪魁祸首。
1 | $ thread -b |
注意， 目前只支持找出 synchronized 关键字阻塞住的线程， 如果是
java.util.concurrent.Lock， 目前还不支持。
thread -i 1000 : 统计最近 1000ms 内的线程 CPU 时间。thread -n 3 -i 1000 : 列出 1000ms 内最忙的 3 个线程栈1 | $ thread -n 3 -i 1000 |
1 | [arthas@28114]$ thread --state WAITING |
通过命令开启采样，观察一段事件后停止，输出一个 html 火焰图文件打开观察即可。1
profiler start
1 | profiler status |
1 | profiler stop |
火焰图的效果大致如下图：
图中的每个色块代表的是一个线程栈帧，色块中是该栈帧加载执行的函数以及一些采样信息。Y 轴代表调用栈的深度，调用从底部开始向上进行，顶部是正在执行的函数，下面是它的父函数，调用栈越深，火焰就越高。X 轴代表抽样数，如果一个函数在 X 轴占据的宽度越大，表示它被抽取到的次数越多，也就意味着它占用的 CPU 时间越长。
需要注意的是，图中的颜色并不重要，只用于区分不同的函数，同时 X 轴的从左到右的顺序也不重要，默认按照字典顺序排序。
我们可以简单举个例子来理解。一般在使用性能分析工具时，我们会选取一个合适的时机启动分析采样，然后等待一段时间后停止采样。假设采样时间为 20 秒，每秒采样 100 次，那么共采样 2000 次，在这 2000 次中，共有 1800 次执行的是 main 方法，其余 200 次执行的是 run 方法，同时 main 方法又调用了很多其他方法，run 方法也是，这就形成了一个从下往上的调用链，在这些调用链中，又同时会收集到每个方法采样的次数，最终形成一张火焰图。
火焰图是可以互动的，点击某个色块，该色块会被放大并占据所有的宽度，这样可以方便地查看某个函数内部的调用链信息。一般观察火焰图，就是看顶层函数占用的宽度，如果有些函数占用的宽度很大，形成了“平顶”，那么就代表该函数可能存在性能问题。当然，有时候直接观察平顶并不能快速定位问题，因为很多时候顶部的函数都是一些底层的库函数，这时候就应该先观察业务代码在火焰图中的宽度，然后再往上观察顶部的库函数来缩小范围。
从上面的火焰图发现TestController类的wl方法占据的 x 轴宽度较长，这是因为我们程序写了一个死循环到消耗了 CPU 。
1 |
|
我们写几个不同循环次数的方法，分别代表方法耗时不同，代码如下：
1 | //示例代码,timeCost是个接口 |
部署之后我们使用 trace 来查找最耗时的方法，在此过程中需要知道包名、类名，以及方法的名字。上述代码方法所在包名为 com.cctest.arthas_demo.controller，类名为 StressSceneController，所以我们需要输入如下 trace 命令：
1 | trace |
输完命令后回车，然后 arthas 程序就进入了等待访问状态。这时候访问接口 /timeCost，我们就可以看到被测程序台在疯狂打印日志，等结束之后，arthas 命令窗口便输出了各方法耗时时间，如图 3 所示：
vmtool –action getInstances –className org.springframework.context.ApplicationContext –express ‘instances[0].getBeanDefinitionNames()’
vmtool –action getInstances –className org.springframework.context.ApplicationContext –express ‘instances[0].getBean(“testController”)’ -x 3
vmtool –action getInstances –className org.springframework.context.ApplicationContext –express ‘instances[0].getBean(“testController”).ok(1)’
ognl 语法：
""主要分为三步：
1 | sc -d cn.lovike.function.osier.core.util.SpringBeanUtils |
1 | [arthas@14466]$ sc -d cn.lovike.function.osier.core.util.SpringBeanUtils |
1 | ognl -c 18b4aac2 -x 3 '@cn.lovike.function.osier.core.util.SpringBeanUtils@getBean("redisUtils").type("osier:sys:dict")' |
返回结果：
ognl -c 2e5d6d97 -x 3 '@com.it.chenyuan.business.utils.SpringUtil@getBean(“MyRedisUtil”).get(“aper_duty_rate:hwzy:1868547696917106690”)’
1 | [HASH] |
1 | ognl -c 18b4aac2 -x 3 '@cn.lovike.function.osier.core.util.SpringBeanUtils@getBean("redisUtils").exists("osier:sys:dict")' |
返回结果：1
[true]
1 | ognl --classLoaderClass org.springframework.boot.loader.LaunchedURLClassLoader '@com.example.demo.arthas.user.UserController@logger.setLevel(@ch.qos.logback.classic.Level@DEBUG)' |
请求接口没有权限的时候一般就返回401 Unauthorized。
401通常是被权限管理的Filter拦截了，那么到底是哪个Filter处理了这个请求，返回了401？
开始trace：
1 | trace javax.servlet.Filter * |
可以在调用树的最深层，找到AdminFilterConfig$AdminFilter返回了401
1 | +---[3.806273ms] javax.servlet.FilterChain:doFilter() |
随着技术的不断发展，后端领域慢慢摒弃传统的单体架构，转而开始流行微服务架构模式。
微服务中将服务按业务拆分的理念确实不错，但福祸相依，单体架构转换为微服务架构的过程中，不可避免的会遇到一些问题。
我们首先遇到的一个问题就是——如何去管理这些拆分出来的服务？
假设现在一个系统存在 A、B、C 三个应用，每个应用部署三份，则现在存在了 A1、A2、A3、B1、B2、B3、C1、C2、C3 共九个应用。
这些应用并非各为孤岛，而是彼此联系，需要相互调用，比如 A –> B –> C（ A 应用需要调用 B，B 调用 C）。
在调用的时间轴中，不得不考虑以下问题：
经以上分析，我们发现——微服务中迫切需要一个组件来管理大量微服务，这个组件一般被称为注册中心。
除此之外，我们还发现多应用中，冗余了大量重复的的配置属性，比如说：
这些属性部分重复且应用一经发布若想二次修改，则必须重启应用才能生效，另外，不同环境的各种属性配置又不一样。
那么，思考这些问题：
经以上分析，我们发现——微服务中迫切需要一个组件来管理大量微服务的配置属性，这个组件一般被称为配置中心。
那么，市面上有没有一个框架，既可当成注册中心，又可充当配置中心，两全其美的解决上面我们遇到的问题呢？
当然是有滴啦，Nacos 就可以充当这两个角色，并且其更加强大。