InsttoolCacheScheduler_ Worker-2 | Quartz | InsttoolCacheScheduler_Worker-2线程就是ThreadPool线程的一个简单实现,它主要负责分配线程资源去执行InsttoolCacheScheduler_QuartzSchedulerThread线程交给它的调度任务(也就是JobRunShell)。 |
java.util.concurrent. ThreadPoolExecutor$Worker | JVM | |
JBossLifeThread | Jboss | Jboss主线程启动成功,应用程序部署完毕之后将JBossLifeThread线程实例化并且start,JBossLifeThread线程启动成功之后就处于等待状态,以保持Jboss Java进程处于存活中。 所得比较通俗一点,就是Jboss启动流程执行完毕之后,为什么没有结束?就是因为有这个线程hold主了它。牛b吧~~ |
JBoss System Threads(1)-1 | Jboss | 该线程是一个socket服务,默认端口号为:1099。主要用于接收外部naming service(Jboss JNDI)请求。 |
JCA PoolFiller | Jboss | 该线程主要为JBoss内部提供连接池的托管。 简单介绍一下工作原理 :Jboss内部凡是有远程连接需求的类,都需要实现ManagedConnectionFactory接口,例如需要做JDBC连接的XAManagedConnectionFactory对象,就实现了该接口。然后将XAManagedConnectionFactory对象,还有其它信息一起包装到InternalManagedConnectionPool对象里面,接着将InternalManagedConnectionPool交给PoolFiller对象里面的列队进行管理。 JCA PoolFiller线程会定期判断列队内是否有需要创建和管理的InternalManagedConnectionPool对象,如果有的话,则调用该对象的fillToMin方法,触发它去创建相应的远程连接,并且将这个连接维护到它相应的连接池里面去。 |
JDWP Event Helper Thread | JVM | JDWP是通讯交互协议,它定义了调试器和被调试程序之间传递信息的格式。它详细完整地定义了请求命令、回应数据和错误代码,保证了前端和后端的JVMTI和JDI的通信通畅。 该线程主要负责将JDI事件映射成JVMTI信号,以达到调试过程中操作JVM的目的。 |
JDWP TransportListener: dt_socket | JVM | 该线程是一个Java Debugger的监听器线程,负责受理客户端的debug请求。通常我们习惯将它的监听端口设置为8787。 |
Low MemoryDetector | JVM | 这个线程是负责对可使用内存进行检测,如果发现可用内存低,分配新的内存空间。 |
process reaper | JVM | 该线程负责去执行一个OS命令行的操作。 |
Reference Handler | JVM | JVM在创建main线程后就创建Reference Handler线程,其优先级最高,为10,它主要用于处理引用对象本身(软引用、弱引用、虚引用)的垃圾回收问题。 |
SurrogateLockerThread (CMS) | JVM | 这个线程主要用于配合CMS垃圾回收器使用,它是一个守护线程,其主要负责处理GC过程中,Java层的Reference(指软引用、弱引用等等)与jvm内部层面的对象状态同步。这里对它们的实现稍微做一下介绍:这里拿WeakHashMap做例子,将一些关键点先列出来(我们后面会将这些关键点全部串起来): 1. 我们知道HashMap用Entry[]数组来存储数据的,WeakHashMap也不例外,内部有一个Entry[]数组。 2. WeakHashMap的Entry比较特殊,它的继承体系结构为Entry->WeakReference->Reference。 3. Reference里面有一个全局锁对象:Lock,它也被称为pending_lock. 注意:它是静态对象。 4. Reference 里面有一个静态变量:pending。 5. Reference 里面有一个静态内部类:ReferenceHandler的线程,它在static块里面被初始化并且启动,启动完成后处于wait状态,它在一个Lock同步锁模块中等待。 6. 另外,WeakHashMap里面还实例化了一个ReferenceQueue列队,这个列队的作用,后面会提到。 7. 上面关键点就介绍完毕了,下面我们把他们串起来。 假设,WeakHashMap对象里面已经保存了很多对象的引用。JVM在进行CMS GC的时候,会创建一个ConcurrentMarkSweepThread(简称CMST)线程去进行GC,ConcurrentMarkSweepThread线程被创建的同时会创建一个SurrogateLockerThread(简称SLT)线程并且启动它,SLT启动之后,处于等待阶段。CMST开始GC时,会发一个消息给SLT让它去获取Java层Reference对象的全局锁:Lock。直到CMS GC完毕之后,JVM会将WeakHashMap中所有被回收的对象所属的WeakReference容器对象放入到Reference的pending属性当中(每次GC完毕之后,pending属性基本上都不会为null了),然后通知SLT释放并且notify全局锁:Lock。此时激活了ReferenceHandler线程的run方法,使其脱离wait状态,开始工作了。ReferenceHandler这个线程会将pending中的所有WeakReference对象都移动到它们各自的列队当中,比如当前这个WeakReference属于某个WeakHashMap对象,那么它就会被放入相应的ReferenceQueue列队里面(该列队是链表结构)。当我们下次从WeakHashMap对象里面get、put数据或者调用size方法的时候,WeakHashMap就会将ReferenceQueue列队中的WeakReference依依poll出来去和Entry[]数据做比较,如果发现相同的,则说明这个Entry所保存的对象已经被GC掉了,那么将Entry[]内的Entry对象剔除掉。 |
taskObjectTimerFactory | JVM | 顾名思义,该线程就是用来执行任务的。当我们把一个任务交给Timer对象,并且告诉它执行时间,周期时间后,Timer就会将该任务放入任务列队,并且通知taskObjectTimerFactory线程去处理任务,taskObjectTimerFactory线程会将状态为取消的任务从任务列队中移除,如果任务是非重复执行类型的,则在执行完该任务后,将它从任务列队中移除,如果该任务是需要重复执行的,则计算出它下一次执行的时间点。 |
VM Periodic Task Thread | JVM | 该线程是JVM周期性任务调度的线程,它由WatcherThread创建,是一个单例对象。该线程在JVM内使用得比较频繁,比如:定期的内存监控、JVM运行状况监控,还有我们经常需要去执行一些jstat这类命令查看gc的情况,如下:jstat -gcutil 23483 250 7 这个命令告诉jvm在控制台打印PID为:23483的gc情况,间隔250毫秒打印一次,一共打印7次。 |
VM Thread | JVM | 这个线程就比较牛b了,是jvm里面的线程母体,根据hotspot源码(vmThread.hpp)里面的注释,它是一个单例的对象(最原始的线程)会产生或触发所有其他的线程,这个单个的VM线程是会被其他线程所使用来做一些VM操作(如,清扫垃圾等)。在 VMThread的结构体里有一个VMOperationQueue列队,所有的VM线程操作(vm_operation)都会被保存到这个列队当中,VMThread本身就是一个线程,它的线程负责执行一个自轮询的loop函数(具体可以参考:VMThread.cpp里面的void VMThread::loop()),该loop函数从VMOperationQueue列队中按照优先级取出当前需要执行的操作对象(VM_Operation),并且调用VM_Operation->evaluate函数去执行该操作类型本身的业务逻辑。ps:VM操作类型被定义在vm_operations.hpp文件内,列举几个:ThreadStop、ThreadDump、PrintThreads、GenCollectFull、GenCollectFullConcurrent、CMS_Initial_Mark、CMS_Final_Remark…..有兴趣的同学,可以自己去查看源文件。 |
Java 内部线程
最新推荐文章于 2022-08-05 11:28:57 发布