「java线程追踪」java线程定时任务
本篇文章给大家谈谈java线程追踪，以及java线程定时任务对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
- 1、只有java有在线诊断工具吗
- 2、如何分析线程堆栈
- 3、java 怎么监控linux上线程是否存在
- 4、java 如何获得线程池中正在执行的线程数？
- 5、Java线程池中的核心线程是如何被重复利用的
- 6、如何监视Java多线程的状态
只有java有在线诊断工具吗
Arthas 是Alibaba开源的Java诊断工具。当你遇到以下类似问题而束手无策时，Arthas可以帮助你解决：
这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？
我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？
遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？
线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！
是否有一个全局视角来查看系统的运行状况？
有什么办法可以监控到JVM的实时运行状态？
怎么快速定位应用的热点，生成火焰图？
Arthas支持jdk6+，多种系统版本，采用命令行交互模式，同时提供丰富的tab自动补全功能，进一步方便我们进行问题的定位和诊断
1.2、快速安装
1.2.1、Linux下按
下载arthas-boot.jar，在使用java -jar方式启动即可。
命令
**注意：**在进行第二条命令之前，先运行一个Java程序在内存之中，否则会报错
2、快速入门
2.1、attach一个进程
目标：
1、执行一个jar包
2、通过arthas来attach来追踪
3、进行常用的命令操作
如果端口号被占用，也可以通过命令换成另一个端口号执行。
总结：
1、启动进程
2、启动arthas-boot.jar，进入启动的进程
3、不但可以通过命令行的方式来操作arthas也可以通过浏览器来访问arthas
2.2、常用命令接触
1、dashboard仪表板
2、通过thread命令来获取到arthas-demo进程的Main Class
3、通过jad来反编译Main Clas
4、wathch具体方法
2.2.1.、dashboard仪表板
在这里插入图片描述
2.2.2、通过thread命令来获取到arthas-demo进程的Main Class
在这里插入图片描述
2.2.3、通过jad反编译Main Class
在这里插入图片描述
2.2.4、watch监视
demo.MathGame primeFactors:
demo.MathGame:包名+类名
primeFactors：方法名
returnObj：返回参数的表达式
2.2.5、退出arthas
如果只是退出当前的连接，可以用quit或者exit命令。Attach到目标进程上的arthas还会继续运行，端口会保持开放，下次连接时可以直接连接上。
如果想完全退出arthas，可以执行stop命令
在这里插入图片描述
2.3、基础命令1
1、help：查看所有帮助信息
2、cat：显示文本文件内容
3、grep：匹配查找，和linux中的grep类似，但只能用于管道命令
在这里插入图片描述
4、pwd：显示当先目录的目录地址
5、cls：清屏
2.4、基础命令2
1、session：查看当前会话信息
在这里插入图片描述
2、reset：重置增强类，将被arthas增强过的类全部还原，arthas服务端关闭时会重置所有增强过的类
在这里插入图片描述
在这里插入图片描述
3、version:输出当前目标Java进程所加载 的Arthas版本号
4、quit：退出当前Arthas客户端，其他Arthas客户端不受影响。
5、stop：关闭Arthas服务端，所有Arthas客户端全部退出。
6、keymap：Arthas快捷键列表及自定义快捷键
7、history：和linux系统作用一样 打印命令历史
3、JVM相关命令
1、dashboard
在这里插入图片描述
2、thread 线程相关：查看当前jvm的线程堆栈的信息
在这里插入图片描述
3、jvm 虚拟机相关
4、sysprop 系统属性相关
5、sysenv:查看当前jvm的环境属性
在这里插入图片描述
6、vmoption：查看、更新vm诊断相关的参数
7、getstatic：方便的查看类的静态属性
语法：getstatic 类名 属性名
8、ognl
在这里插入图片描述
3.1、反编译 jad
比如编译string类
–source-only ： 只显示源码
只反编译指定的方法
xx 就是方法名
3.2、内存编译mc
内存编译器，编译.java文件生成.class
在这里插入图片描述
在这里插入图片描述
4、Arthas进阶
4.1、目标
类与类加载器
monitor、watch、trace、stack等核心命令的使用
火焰图的生存
arthas实战案例
4.2、dump
将已加载的字节码文件保存到特定的目录下，logs/arthas/classdump/
在这里插入图片描述
举例：
在这里插入图片描述
4.3、classloader
获取类加载器的信息
作用：
将jvm中所有的classloader的信息统计出来，并可以展示继承树，urls等。
让指定的classloader去getResources，打印出所有查找到的resources的url。
在这里插入图片描述
4.4、monitor
监控指定类中方法的执行情况
作用：
在这里插入图片描述
在这里插入图片描述
4.5、watch（重要）
观察到指定方法的调用情况
作用：
方法执行数据观测，方便观测到指定方法的调用情况
能观察到的范围：返回值、抛出异常、入参。通过编写OGNL表达式进行对应变量的查看
在这里插入图片描述
在这里插入图片描述
只查看第一个参数小于0的情况
在这里插入图片描述
文章知识点与官方知识档案匹配
Java技能树首页概览
89145 人正在系统学习中
打开CSDN，阅读体验更佳
java应用线上诊断神器--Arthas_linyb极客之路的博客
c、保存好/tmp/UserServiceImpl.java之后,使用mc(Memory Compiler)命令来编译,并且通过–classLoaderClass参数指定ClassLoader mc--classLoaderClass org.springframework.boot.loader.LaunchedURLClassLoader/tmp/UserServiceImpl.java-d/tmp ...
继续访问
java线上诊断工具,Java线上诊断神器Arthas-1_Skogkatt的博客-CSDN...
Arthas 是Alibaba 开源的一款线上诊断工具,相比Java 自带的jinfo, jmap,jstat 等工具更方便(起码不用记那么多参数),而且利用字节码增强技术,可以很好的对线上的问题进行定位以及解决,不用再为生产或者测试环境无法debug而感到无能为力。...
继续访问
最新发布 Arthas常用命令
arthas指令大全
继续访问
Arthas在线java进程诊断工具 在线调试神器
Arthas在线java进程诊断工具 在线调试神器 tag: java 诊断 堆栈 在线调试 耗时 死锁 arthas 阿里巴巴 Arthas 是 Alibaba 开源的Java诊断工具，深受开发者喜爱。 官网文档： 当你遇到以下类似问题而束手无策时，Arthas可以帮助你解决： 这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？ 我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？ 遇到问题无法在.
继续访问
Java在线诊断利器之Arthas_Java老K的博客
Arthas是阿里在2019年9月份开源的一款java在线诊断工具,能够分析、诊断、定位java应用问题,例如:jvm信息、线程信息、搜索类中的方法、 跟踪代码执行、观测方法的入参和返回参数等等。 Arthas最大的特点是能在不修改代码和不需要重新发布的...
继续访问
java线上诊断神器 --Arthas__小鱼塘的博客_java网络诊断
java线上诊断神器 --Arthas 最近在工作中用到的一个非常很好的线上诊断,分析问题的神器,再次记录一下: 官方文档:简介 | arthas GitHub 地址:GitHub - alibaba/arthas: Alibaba Java Diagnostic Tool Arthas/Alibaba Java诊断利器Arthas...
继续访问
Arthas使用教程(8大分类)
1、基础命令。2、JVM相关。3、类与类加载器。4、option全局选项。5、项目中使用案例。
继续访问
Arthas介绍
这篇文章为大家推荐一个为Java应用程序排查问题的非常好用的工具：Arthas，首先声明一下，这边文章并不是教大家如何使用，它只是一个搬运工，在Arthas的github上已经有非常详细的使用教程了。 Arthas（阿尔萨斯）是阿里巴巴开源的Java诊断工具，深受开发者喜爱 当你遇到以下类似问题而束手无策时，Arthas统统可以帮你解决 某个类是从哪个jar包加载的，为什么会报各种类相关的Exc...
继续访问
Arthas - Java线上诊断工具_是良辰的博客
java -jar arthas-boot.jar 启动之后就可以看到一个java程序列表,像我这就是只有一个java程序在跑,就是当前根目录下面的app.jar 选择1,即可对app.jar进行监控诊断。 PS:如果是虚拟机,直接在应用服务器上面执行上面的命令,如果是docke...
继续访问
java线上诊断工具Arthas-实战案例_小姐姐修灯泡吗的博客
首先我就来简单介绍下他的作用:(粘贴官网)Arthas 是Alibaba开源的Java诊断工具,深受开发者喜爱。在线排查问题,无需重启;动态跟踪Java代码;实时监控JVM状态。 Arthas 支持JDK 6+,支持Linux/Mac/Windows,采用命令行交互模式,同时提供丰富的...
继续访问
arthas 使用教程
arthas安装使用 首先是安装，说白了其实把他当成一个工具来用就行了，你什么服务需要在线进行性能情况的一个监测和性能的瓶颈排查。第三步启动arthas-boot.jar，启动的时候要注意你需要监测的java是启动的可以用jps-l命令查看你的java服务。第二步把jar包上传到你需要进行java性能监测的服务器上。线上正式环境把他当成一个排查慢问题的工具还是很好用的。以上就是启动服务了下面开始介绍常用的一些排查命令。...
继续访问
Arthas
Arthas.md 当你遇到以下类似问题而束手无策时，Arthas可以帮助你解决： 这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？ 我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？ 遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？ 线上遇到某个用户的数据处理有问题，...
继续访问
Java线上问题诊断工具Arthas_星光Starsray的博客
java -jar arthas-boot.jar //启动 当看到控制台出现arthas的标志,表明启动成功!注意此时已经进入控制台,主要是arthas的命令使用。 [root@xxptweb01 arthas]# java -jar arthas-boot.jar
继续访问
【Java】性能问题诊断利器Arthas --常用命令示例_叹了口丶气的博客-C...
Arthas 是一款阿里开源的 Java 线上诊断工具,功能强大,可以在不修改代码或者重启服务的情况下快速定位线上问题。 官方文档:Arthas官网 二、安装 从官网下载 Arthas 全量包安装(因为快速安装可能因网络原因下载失败),然后用 java -jar 方...
继续访问
Java诊断工具Arthas使用说明
Arthas 是Alibaba开源的Java诊断工具，Arthas支持JDK 6+，支持Linux/Mac/Windows，支持命令行交互模式、 Tab 自动补全功能，方便进行问题的定位和诊断。
继续访问
JVM性能调优篇07-阿里巴巴Arthas工具详解
阿里巴巴Arthas工具详解
继续访问
Arthas 是Alibaba开源的Java诊断工具
Arthas是Alibaba开源的Java诊断工具，深受开发者喜爱。 当你遇到以下类似问题而束手无策时，Arthas可以帮助你解决： 这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？ 我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？ 遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？ 线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！ 是否有一个全局视角来查看系统的运行...
继续访问
JVM之GC 调优工具 Arthas 实战使用（二）
Arthas 是 Alibaba 开源的 Java 诊断工具，深受开发者喜爱。Arthas 支持 JDK 6以上版本，支持 Linux/Mac/Windows，而且这些环境的命令都一样，采用命令行交互模式，同时提供丰富的 Tab 自动补全功能，进行问题的定位和诊断 官方文档参考 一、下载和安装 不需要安装，就是一个 jar 包 curl -O
继续访问
Arthas详解
文章目录概述安装快速安装使用`arthas-boot`（官网推荐）使用`as.sh`全量安装把Arthas安装到基础镜像里卸载使用命令详解基础命令helpcatechogrepbase64teepwdclsversionhistorykeymap后台异步命令相关快捷键会话相关quitstopsessionresetjvm相关dashboardthreadjvmsyspropsysenvvmoptionperfcounterloggergetstaticognlmbeanheapdumpvmtoolclass
继续访问
Arthas基础
Arthas：快速入门
继续访问
Arthas入门到精通
Arthas是Alibaba开源的一款Java诊断工具，方便开发者在线排查问题，无需重启，同时可以跟踪Java代码，实时监控JVM状态，目前Arthas仅支持JDK6+，支持Linux/Mac/Windows，采用命令行交互模式，具有 Tab 自动补全功能，便于开发者进行快速定位和诊断问题。 离线全量下载（如果服务器没有外网可以采用这种情况）
继续访问
阿里Java诊断工具 arthas - 介绍及指令大全
一、arthas Arthas` 是Alibaba开源的Java诊断工具，深受开发者喜爱。 当你遇到以下类似问题而束手无策时，Arthas可以帮助你解决： 这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？ 我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？ 遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？ 线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！ 是否有一个全局视角来查看系统的运行状况？ 有什么办法可以监控到
继续访问
java诊断神器 arthas(阿尔萨斯)
java诊断神器 arthas(阿尔萨斯) 官网地址： 1、快速开始 1.1、windows版本安装 # 命令行输入 curl -0 --output arthas-boot.jar # 启动arthas 注意：启动前已经要有java进程运行，否则无法进入 java -jar arthas-boot.jar --telnet-por
继续访问
帮助定位Java方法优化之arthas端口被占用解决的办法
另起一个端口号 启动arthas命令的后面加上端口号的相关参数 java -jar arthas-boot.jar --telnet-port 端口号 --http-port -1 关闭占用端口的服务 先进入占用端口的服务，然后输入stop将它停掉就可以了 注：请再每一次使用之后使用stop命令退出，这样也省掉一些不必要的麻烦！！！ ...
继续访问
Java 诊断工具之 Arthas
Arthas 是 Alibaba 开源的 Java 诊断工具。Ta 可以动态跟踪 Java 代码，实时监控 JVM 状态，可以在不中断程序执行的情况下轻松完成 JVM 相关问题排查工作。支持 JDK 6+，支持 Linux/Mac/Windows。
继续访问
Arthas-java在线调试工具的使用
一、arthas能干什么？ 这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？ 我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？ 遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？ 线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！ 是否有一个全局视角来查看系统的运行状况？ 有什么办法可以监控到JVM的实时运行状态？ 怎么快速定位应用的热点，生成火焰图？ 怎样直接从JVM内查找某个类的实例？ Arthas支持JDK 6+
继续访问
Java线上诊断工具Arthas
概述 Arthas是一个开源的线上诊断工具，可以实时查看线上代码运行情况，详情参考Arthas 命令列表 jad命令（获取已加载类的源码） //主要用来看已经加载了类的源码，一般用于动态加载的class的源码比较方便 [arthas@773]$ jad com/example/jvm/Hello ClassLoader: +-sun.misc.Launcher$AppClassLoader@18b4aac2 +-sun.misc.Launcher$ExtClassLoader@362d9..
继续访问
java 线上诊断命令
java
学习
如何分析线程堆栈
JVM线程堆栈是一个给定时间的快照，它能向你提供所有被创建出来的Java线程的完整清单.
每一个被发现的Java线程都会给你如下信息:
– 线程的名称；经常被中间件厂商用来识别线程的标识，一般还会带上被分配的线程池名称以及状态 (运行，阻塞等等.)
– 线程类型 优先级，例如 : daemon prio=3 ** 中间件程序一般以后台守护的形式创建他们的线程，这意味着这些线程是在后台运行的；它们会向它们的用户提供服务，例如：向你的Java EE应用程序 **
– Java线程ID，例如 : tid=0x000000011e52a800 ** 这是通过 java.lang.Thread.getId() 获得的Java线程ID，它常常用自增长的长整形 1..n** 实现
– 原生线程ID，例如 : nid=0x251c** ，之所以关键是因为原生线程ID可以让你获得诸如从操作系统的角度来看那个线程在你的JVM中使用了大部分的CPU时间等这样的相关信息. **
– Java线程状态和详细信息，例如: waiting for monitor entry [0xfffffffea5afb000] java.lang.Thread.State: BLOCKED (on object monitor)
** 可以快速的了解到线程状态极其当前阻塞的可能原因 **
– Java线程栈跟踪；这是目前为止你能从线程堆栈中找到的最重要的数据. 这也是你花费最多分析时间的地方，因为Java栈跟踪向提供了你将会在稍后的练习环节了解到的导致诸多类型的问题的根本原因，所需要的90%的信息。
– Java 堆内存分解; 从HotSpot VM 1.6版本开始，在线程堆栈的末尾处可以看到HotSpot的内存使用情况，比如说Java的堆内存(YoungGen, OldGen) PermGen 空间。这个信息对分析由于频繁GC而引起的问题时，是很有用的。你可以使用已知的线程数据或模式做一个快速的定位。
Heap
PSYoungGen total 466944K, used 178734K [0xffffffff45c00000, 0xffffffff70800000, 0xffffffff70800000)
eden space 233472K, 76% used [0xffffffff45c00000,0xffffffff50ab7c50,0xffffffff54000000)
from space 233472K, 0% used [0xffffffff62400000,0xffffffff62400000,0xffffffff70800000)
to space 233472K, 0% used [0xffffffff54000000,0xffffffff54000000,0xffffffff62400000)
PSOldGen total 1400832K, used 1400831K [0xfffffffef0400000, 0xffffffff45c00000, 0xffffffff45c00000)
object space 1400832K, 99% used [0xfffffffef0400000,0xffffffff45bfffb8,0xffffffff45c00000)
PSPermGen total 262144K, used 248475K [0xfffffffed0400000, 0xfffffffee0400000, 0xfffffffef0400000)
object space 262144K, 94% used [0xfffffffed0400000,0xfffffffedf6a6f08,0xfffffffee0400000)
线程堆栈信息大拆解
为了让大家更好的理解，给大家提供了下面的这张图，在这张图中将HotSpot VM上的线程堆栈信息和线程池做了详细的拆解，如下图所示：
上图中可以看出线程堆栈是由多个不同部分组成的。这些信息对问题分析都很重要，但对不同的问题模式的分析会使用不同的部分（问题模式会在后面的文章中做模拟和演示。）
现在通过这个分析样例，给大家详细解释一下HoteSpot上线程堆栈信息中的各个组成部分：
# Full thread dump标示符
“Full thread dump”是一个全局唯一的关键字，你可以在中间件和单机版本Java的线程堆栈信息的输出日志中找到它（比如说在UNIX下使用：kill -3 PID ）。这是线程堆栈快照的开始部分。
Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode):
# Java EE 中间件,第三方以及自定义应用软件中的线程
这个部分是整个线程堆栈的核心部分，也是通常需要花费最多分析时间的部分。堆栈中线程的个数取决你使用的中间件，第三方库（可能会有独立线程）以及你的应用程序（如果创建自定义线程，这通常不是一个很好的实践）。
在我们的示例线程堆栈中，WebLogic是我们所使用的中间件。从Weblogic 9.2开始, 会使用一个用“’weblogic.kernel.Default (self-tuning)”唯一标识的能自行管理的线程池
"[STANDBY] ExecuteThread: '414' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=3 tid=0x000000010916a800 nid=0x2613 in Object.wait() [0xfffffffe9edff000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xffffffff27d44de0 (a weblogic.work.ExecuteThread)
at java.lang.Object.wait(Object.java:485)
at weblogic.work.ExecuteThread.waitForRequest(ExecuteThread.java:160)
- locked 0xffffffff27d44de0 (a weblogic.work.ExecuteThread)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
# HotSpot VM 线程
这是一个有Hotspot VM管理的内部线程，用于执行内部的原生操作。一般你不用对此操太多心，除非你(通过相关的线程堆栈以及 prstat或者原生线程Id)发现很高的CPU占用率.
"VM Periodic Task Thread" prio=3 tid=0x0000000101238800 nid=0x19 waiting on condition
# HotSpot GC 线程
当使用 HotSpot 进行并行 GC (如今在使用多个物理核心的环境下很常见), 默认创建的HotSpot VM 或者每个JVM管理一个有特定标识的GC线程时. 这些GC线程可以让VM以并行的方式执行其周期性的GC清理, 这会导致GC时间的总体减少；与此同时的代价是CPU的使用时间会增加.
"GC task thread#0 (ParallelGC)" prio=3 tid=0x0000000100120000 nid=0x3 runnable
"GC task thread#1 (ParallelGC)" prio=3 tid=0x0000000100131000 nid=0x4 runnable
………………………………………………………………………………………………………………………………………………………………
这事非常关键的数据，因为当你遇到跟GC有关的问题，诸如过度GC、内存泄露等问题是，你将可以利用这些线程的原生Id值关联的操作系统或者Java线程，进而发现任何对CPI时间的高占用. 未来的文章你将会了解到如何识别并诊断这样的问题.
# JNI 全局引用计数
JNI (Java 本地接口)的全局引用就是从本地代码到由Java垃圾收集器管理的Java对象的基本的对象引用. 它的角色就是阻止对仍然在被本地代码使用，但是技术上已经不是Java代码中的“活动的”引用了的对象的垃圾收集.
同时为了侦测JNI相关的泄露而留意JNI引用也很重要. 如果你的程序直接使用了JNI，或者像监听器这样的第三方工具，就容易造成本地的内存泄露.
JNI global references: 1925
# Java 堆栈使用视图
这些数据被添加回了 JDK 1 .6 ，向你提供有关Hotspot堆栈的一个简短而快速的视图. 我发现它在当我处理带有过高CPU占用的GC相关的问题时非常有用，你可以在一个单独的快照中同时看到线程堆栈以及Java堆的信息，让你当时就可以在一个特定的Java堆内存空间中解析（或者排除）出任何的关键点. 你如在我们的示例线程堆栈中所见，Java 的堆 OldGen 超出了最大值!
Heap
PSYoungGen total 466944K, used 178734K [0xffffffff45c00000, 0xffffffff70800000, 0xffffffff70800000)
eden space 233472K, 76% used [0xffffffff45c00000,0xffffffff50ab7c50,0xffffffff54000000)
from space 233472K, 0% used [0xffffffff62400000,0xffffffff62400000,0xffffffff70800000)
to space 233472K, 0% used [0xffffffff54000000,0xffffffff54000000,0xffffffff62400000)
PSOldGen total 1400832K, used 1400831K [0xfffffffef0400000, 0xffffffff45c00000, 0xffffffff45c00000)
object space 1400832K, 99% used [0xfffffffef0400000,0xffffffff45bfffb8,0xffffffff45c00000)
PSPermGen total 262144K, used 248475K [0xfffffffed0400000, 0xfffffffee0400000, 0xfffffffef0400000)
object space 262144K, 94% used [0xfffffffed0400000,0xfffffffedf6a6f08,0xfffffffee0400000)
我希望这篇文章能对你理解Hotspot VM线程堆栈的基本信息有所帮助。
java 怎么监控linux上线程是否存在
CPU资源时，按照以下步骤进行查找：
(一)：通过【 top -p 12377 -H】 查看java进程的有哪些线程的运行情况；
和通过【jstack 12377 stack.log】生成Java线程的dump详细信息；
先用top命令找出占用资源厉害的java进程id，如图：# top
如上图所示，java的进程id为’52554′，接下来用top命令单独对这个进程中的所有线程作监视：
1 top -p 52554 -H
# top视图里面里面可以通过快捷键依次b ,x高亮显示top的列找出需要的线程，默认CPU排序，Sh
java 如何获得线程池中正在执行的线程数？
java中线程池的监控可以检测到正在执行的线程数。
通过线程池提供的参数进行监控。线程池里有一些属性在监控线程池的时候可以使用
taskCount：线程池需要执行的任务数量。
completedTaskCount：线程池在运行过程中已完成的任务数量。小于或等于taskCount。
largestPoolSize：线程池曾经创建过的最大线程数量。通过这个数据可以知道线程池是否满过。如等于线程池的最大大小，则表示线程池曾经满了。
getPoolSize:线程池的线程数量。如果线程池不销毁的话，池里的线程不会自动销毁，所以这个大小只增不+ getActiveCount：获取活动的线程数。
通过扩展线程池进行监控。通过继承线程池并重写线程池的beforeExecute，afterExecute和terminated方法，我们可以在任务执行前，执行后和线程池关闭前干一些事情。如监控任务的平均执行时间，最大执行时间和最小执行时间等。这几个方法在线程池里是空方法。如：
protected void beforeExecute(Thread t, Runnable r) { }
Java线程池中的核心线程是如何被重复利用的
Java线程池中的核心线程是如何被重复利用的？
引言
在Java开发中，经常需要创建线程去执行一些任务，实现起来也非常方便，但如果并发的线程数量很多，并且每个线程都是执行一个时间很短的任务就结束了，这样频繁创建线程就会大大降低系统的效率，因为频繁创建线程和销毁线程需要时间。此时，我们很自然会想到使用线程池来解决这个问题。
使用线程池的好处：
降低资源消耗。java中所有的池化技术都有一个好处，就是通过复用池中的对象，降低系统资源消耗。设想一下如果我们有n多个子任务需要执行，如果我们为每个子任务都创建一个执行线程，而创建线程的过程是需要一定的系统消耗的，最后肯定会拖慢整个系统的处理速度。而通过线程池我们可以做到复用线程，任务有多个，但执行任务的线程可以通过线程池来复用，这样减少了创建线程的开销，系统资源利用率得到了提升。
降低管理线程的难度。多线程环境下对线程的管理是最容易出现问题的，而线程池通过框架为我们降低了管理线程的难度。我们不用再去担心何时该销毁线程，如何最大限度的避免多线程的资源竞争。这些事情线程池都帮我们代劳了。
提升任务处理速度。线程池中长期驻留了一定数量的活线程，当任务需要执行时，我们不必先去创建线程，线程池会自己选择利用现有的活线程来处理任务。
很显然，线程池一个很显著的特征就是“长期驻留了一定数量的活线程”，避免了频繁创建线程和销毁线程的开销，那么它是如何做到的呢？我们知道一个线程只要执行完了run()方法内的代码，这个线程的使命就完成了，等待它的就是销毁。既然这是个“活线程”，自然是不能很快就销毁的。为了搞清楚这个“活线程”是如何工作的，下面通过追踪源码来看看能不能解开这个疑问。
分析方法
在分析源码之前先来思考一下要怎么去分析，源码往往是比较复杂的，如果知识储备不够丰厚，很有可能会读不下去，或者读岔了。一般来讲要时刻紧跟着自己的目标来看代码，跟目标关系不大的代码可以不理会它，一些异常的处理也可以暂不理会，先看正常的流程。就我们现在要分析的源码而言，目标就是看看线程是如何被复用的。那么对于线程池的状态的管理以及非正常状态下的处理代码就可以不理会，具体来讲，在ThreadPollExcutor类中，有一个字段 private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0)); 是对线程池的运行状态和线程池中有效线程的数量进行控制的， 它包含两部分信息: 线程池的运行状态 (runState) 和线程池内有效线程的数量 (workerCount)，还有几个对ctl进行计算的方法:
// 获取运行状态
private static int runStateOf(int c) { return c ~CAPACITY; }
// 获取活动线程数
private static int workerCountOf(int c) { return c CAPACITY; }123456
以上两个方法在源码中经常用到，结合我们的目标，对运行状态的一些判断及处理可以不用去管，而对当前活动线程数要加以关注等等。
下面将遵循这些原则来分析源码。
解惑
当我们要向线程池添加一个任务时是调用ThreadPollExcutor对象的execute(Runnable command)方法来完成的，所以先来看看ThreadPollExcutor类中的execute(Runnable command)方法的源码：
public void execute(Runnable command) {
if (command == null)
throw new NullPointerException();
int c = ctl.get();
if (workerCountOf(c) corePoolSize) {
if (addWorker(command, true))
return;
c = ctl.get();
}
if (isRunning(c) workQueue.offer(command)) {
int recheck = ctl.get();
if (! isRunning(recheck) remove(command))
reject(command);
else if (workerCountOf(recheck) == 0)
addWorker(null, false);
}
else if (!addWorker(command, false))
reject(command);
}123456789101112131415161718192021
按照我们在分析方法中提到的一些原则，去掉一些相关性不强的代码，看看核心代码是怎样的。
// 为分析而简化后的代码
public void execute(Runnable command) {
int c = ctl.get();
if (workerCountOf(c) corePoolSize) {
// 如果当前活动线程数小于corePoolSize，则新建一个线程放入线程池中，并把任务添加到该线程中
if (addWorker(command, true))
return;
c = ctl.get();
}
// 如果当前活动线程数大于等于corePoolSize，则尝试将任务放入缓存队列
if (workQueue.offer(command)) {
int recheck = ctl.get();
if (workerCountOf(recheck) == 0)
addWorker(null, false);
}else {
// 缓存已满，新建一个线程放入线程池，并把任务添加到该线程中（此时新建的线程相当于非核心线程）
addWorker(command, false)
}
}12345678910111213141516171819202122
这样一看，逻辑应该清晰很多了。
如果 当前活动线程数 指定的核心线程数，则创建并启动一个线程来执行新提交的任务（此时新建的线程相当于核心线程）；
如果 当前活动线程数 = 指定的核心线程数，且缓存队列未满，则将任务添加到缓存队列中；
如果 当前活动线程数 = 指定的核心线程数，且缓存队列已满，则创建并启动一个线程来执行新提交的任务（此时新建的线程相当于非核心线程）；
接下来看 addWorker(Runnable firstTask, boolean core)方法
private boolean addWorker(Runnable firstTask, boolean core) {
retry:
for (;;) {
int c = ctl.get();
int rs = runStateOf(c);
// Check if queue empty only if necessary.
if (rs = SHUTDOWN
! (rs == SHUTDOWN
firstTask == null
! workQueue.isEmpty()))
return false;
for (;;) {
int wc = workerCountOf(c);
if (wc = CAPACITY ||
wc = (core ? corePoolSize : maximumPoolSize))
return false;
if (compareAndIncrementWorkerCount(c))
break retry;
c = ctl.get(); // Re-read ctl
if (runStateOf(c) != rs)
continue retry;
// else CAS failed due to workerCount change; retry inner loop
}
}
boolean workerStarted = false;
boolean workerAdded = false;
Worker w = null;
try {
w = new Worker(firstTask);
final Thread t = w.thread;
if (t != null) {
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
// Recheck while holding lock.
// Back out on ThreadFactory failure or if
// shut down before lock acquired.
int rs = runStateOf(ctl.get());
if (rs SHUTDOWN ||
(rs == SHUTDOWN firstTask == null)) {
if (t.isAlive()) // precheck that t is startable
throw new IllegalThreadStateException();
workers.add(w);
int s = workers.size();
if (s largestPoolSize)
largestPoolSize = s;
workerAdded = true;
}
} finally {
mainLock.unlock();
}
if (workerAdded) {
t.start();
workerStarted = true;
}
}
} finally {
if (! workerStarted)
addWorkerFailed(w);
}
return workerStarted;
}12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667
同样，我们也来简化一下：
// 为分析而简化后的代码
private boolean addWorker(Runnable firstTask, boolean core) {
int wc = workerCountOf(c);
if (wc = (core ? corePoolSize : maximumPoolSize))
// 如果当前活动线程数 = 指定的核心线程数，不创建核心线程
// 如果当前活动线程数 = 指定的最大线程数，不创建非核心线程
return false;
boolean workerStarted = false;
boolean workerAdded = false;
Worker w = null;
try {
// 新建一个Worker，将要执行的任务作为参数传进去
w = new Worker(firstTask);
final Thread t = w.thread;
if (t != null) {
workers.add(w);
workerAdded = true;
if (workerAdded) {
// 启动刚刚新建的那个worker持有的线程，等下要看看这个线程做了啥
t.start();
workerStarted = true;
}
}
} finally {
if (! workerStarted)
addWorkerFailed(w);
}
return workerStarted;
}1234567891011121314151617181920212223242526272829303132
看到这里，我们大概能猜测到，addWorker方法的功能就是新建一个线程并启动这个线程，要执行的任务应该就是在这个线程中执行。为了证实我们的这种猜测需要再来看看Worker这个类。
private final class Worker
extends AbstractQueuedSynchronizer
implements Runnable{
// ....
}
Worker(Runnable firstTask) {
setState(-1); // inhibit interrupts until runWorker
this.firstTask = firstTask;
this.thread = getThreadFactory().newThread(this);
}123456789101112
从上面的Worker类的声明可以看到，它实现了Runnable接口，以及从它的构造方法中可以知道待执行的任务赋值给了它的变量firstTask，并以它自己为参数新建了一个线程赋值给它的变量thread，那么运行这个线程的时候其实就是执行Worker的run()方法，来看一下这个方法：
public void run() {
runWorker(this);
}
final void runWorker(Worker w) {
Thread wt = Thread.currentThread();
Runnable task = w.firstTask;
w.firstTask = null;
w.unlock(); // allow interrupts
boolean completedAbruptly = true;
try {
while (task != null || (task = getTask()) != null) {
w.lock();
// If pool is stopping, ensure thread is interrupted;
// if not, ensure thread is not interrupted. This
// requires a recheck in second case to deal with
// shutdownNow race while clearing interrupt
if ((runStateAtLeast(ctl.get(), STOP) ||
(Thread.interrupted()
runStateAtLeast(ctl.get(), STOP)))
!wt.isInterrupted())
wt.interrupt();
try {
beforeExecute(wt, task);
Throwable thrown = null;
try {
task.run();
} catch (RuntimeException x) {
thrown = x; throw x;
} catch (Error x) {
thrown = x; throw x;
} catch (Throwable x) {
thrown = x; throw new Error(x);
} finally {
afterExecute(task, thrown);
}
} finally {
task = null;
w.completedTasks++;
w.unlock();
}
}
completedAbruptly = false;
} finally {
processWorkerExit(w, completedAbruptly);
}
}123456789101112131415161718192021222324252627282930313233343536373839404142434445464748
在run()方法中只调了一下 runWorker(this) 方法，再来简化一下这个 runWorker() 方法
// 为分析而简化后的代码
final void runWorker(Worker w) {
Runnable task = w.firstTask;
w.firstTask = null;
while (task != null || (task = getTask()) != null) {
try {
task.run();
} finally {
task = null;
}
}
}12345678910111213
很明显，runWorker()方法里面执行了我们新建Worker对象时传进去的待执行的任务，到这里为止貌似这个worker的run()方法就执行完了，既然执行完了那么这个线程也就没用了，只有等待虚拟机销毁了。那么回顾一下我们的目标：Java线程池中的核心线程是如何被重复利用的？好像并没有重复利用啊，新建一个线程，执行一个任务，然后就结束了，销毁了。没什么特别的啊，难道有什么地方漏掉了，被忽略了？再仔细看一下runWorker()方法的代码，有一个while循环，当执行完firstTask后task==null了，那么就会执行判断条件 (task = getTask()) != null，我们假设这个条件成立的话，那么这个线程就不止只执行一个任务了，可以执行多个任务了，也就实现了重复利用了。答案呼之欲出了，接着看getTask()方法
private Runnable getTask() {
boolean timedOut = false; // Did the last poll() time out?
for (;;) {
int c = ctl.get();
int rs = runStateOf(c);
// Check if queue empty only if necessary.
if (rs = SHUTDOWN (rs = STOP || workQueue.isEmpty())) {
decrementWorkerCount();
return null;
}
int wc = workerCountOf(c);
// Are workers subject to culling?
boolean timed = allowCoreThreadTimeOut || wc corePoolSize;
if ((wc maximumPoolSize || (timed timedOut))
(wc 1 || workQueue.isEmpty())) {
if (compareAndDecrementWorkerCount(c))
return null;
continue;
}
try {
Runnable r = timed ?
workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
workQueue.take();
if (r != null)
return r;
timedOut = true;
} catch (InterruptedException retry) {
timedOut = false;
}
}
}1234567891011121314151617181920212223242526272829303132333435363738
老规矩，简化一下代码来看：
// 为分析而简化后的代码
private Runnable getTask() {
boolean timedOut = false;
for (;;) {
int c = ctl.get();
int wc = workerCountOf(c);
// timed变量用于判断是否需要进行超时控制。
// allowCoreThreadTimeOut默认是false，也就是核心线程不允许进行超时；
// wc corePoolSize，表示当前线程池中的线程数量大于核心线程数量；
// 对于超过核心线程数量的这些线程，需要进行超时控制
boolean timed = allowCoreThreadTimeOut || wc corePoolSize;
if (timed timedOut) {
// 如果需要进行超时控制，且上次从缓存队列中获取任务时发生了超时，那么尝试将workerCount减1,即当前活动线程数减1，
// 如果减1成功，则返回null，这就意味着runWorker()方法中的while循环会被退出，其对应的线程就要销毁了，也就是线程池中少了一个线程了
if (compareAndDecrementWorkerCount(c))
return null;
continue;
}
try {
Runnable r = timed ?
workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
workQueue.take();
// 注意workQueue中的poll()方法与take()方法的区别
//poll方式取任务的特点是从缓存队列中取任务,最长等待keepAliveTime的时长，取不到返回null
//take方式取任务的特点是从缓存队列中取任务，若队列为空,则进入阻塞状态，直到能取出对象为止
if (r != null)
return r;
timedOut = true;
} catch (InterruptedException retry) {
timedOut = false;
}
}
}123456789101112131415161718192021222324252627282930313233343536373839
从以上代码可以看出，getTask()的作用是
如果当前活动线程数大于核心线程数，当去缓存队列中取任务的时候，如果缓存队列中没任务了，则等待keepAliveTime的时长，此时还没任务就返回null，这就意味着runWorker()方法中的while循环会被退出，其对应的线程就要销毁了，也就是线程池中少了一个线程了。因此只要线程池中的线程数大于核心线程数就会这样一个一个地销毁这些多余的线程。
如果当前活动线程数小于等于核心线程数，同样也是去缓存队列中取任务，但当缓存队列中没任务了，就会进入阻塞状态，直到能取出任务为止，因此这个线程是处于阻塞状态的，并不会因为缓存队列中没有任务了而被销毁。这样就保证了线程池有N个线程是活的，可以随时处理任务，从而达到重复利用的目的。
小结
通过以上的分析，应该算是比较清楚地解答了“线程池中的核心线程是如何被重复利用的”这个问题，同时也对线程池的实现机制有了更进一步的理解：
当有新任务来的时候，先看看当前的线程数有没有超过核心线程数，如果没超过就直接新建一个线程来执行新的任务，如果超过了就看看缓存队列有没有满，没满就将新任务放进缓存队列中，满了就新建一个线程来执行新的任务，如果线程池中的线程数已经达到了指定的最大线程数了，那就根据相应的策略拒绝任务。
当缓存队列中的任务都执行完了的时候，线程池中的线程数如果大于核心线程数，就销毁多出来的线程，直到线程池中的线程数等于核心线程数。此时这些线程就不会被销毁了，它们一直处于阻塞状态，等待新的任务到来。
注意：
本文所说的“核心线程”、“非核心线程”是一个虚拟的概念，是为了方便描述而虚拟出来的概念，在代码中并没有哪个线程被标记为“核心线程”或“非核心线程”，所有线程都是一样的，只是当线程池中的线程多于指定的核心线程数量时，会将多出来的线程销毁掉，池中只保留指定个数的线程。那些被销毁的线程是随机的，可能是第一个创建的线程，也可能是最后一个创建的线程，或其它时候创建的线程。一开始我以为会有一些线程被标记为“核心线程”，而其它的则是“非核心线程”，在销毁多余线程的时候只销毁那些“非核心线程”，而“核心线程”不被销毁。这种理解是错误的。
另外还有一个重要的接口 BlockingQueue 值得去了解，它定义了一些入队出队同步操作的方法，还可以阻塞，作用很大。
如何监视Java多线程的状态
线程池的地方在新增或者删除线程的时候加一个debug信息。
如果在命令行下面启动的话用ctrl + break就可以看到当前哪些线程在运行了。。。
关于java线程追踪和java线程定时任务的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。