JVM线程分析详解

java线程状态：
在这里插入图片描述

  1. 初始(NEW)：新创建了一个线程对象，但还没有调用start()方法。
  2. 运行(RUNNABLE)：Java线程中将就绪（ready）和运行中（running）两种状态笼统的称为“运行”。
    线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取CPU的使用权，此时处于就绪状态（ready）。就绪状态的线程在获得CPU时间片后变为运行中状态（running）。
  3. 阻塞(BLOCKED)：表示线程阻塞于锁。
  4. 等待(WAITING)：进入该状态的线程需要等待其他线程做出一些特定动作（通知或中断）。
  5. 超时等待(TIMED_WAITING)：该状态不同于WAITING，它可以在指定的时间后自行返回。
  6. 终止(TERMINATED)：表示该线程已经执行完毕。

Java Monitor原理：
Monitor 是Java中用以实现线程之间的互斥与协作的主要手段，可以看成是对象或者Class的锁。每一个对象有且仅有一个monitor。Java 的 Object 类本身就是监视者对象，Java 对于 Monitor Object 模式做了内建的支持。
Object 类本身就是监视者对象！
每个 Object 都带了一把看不见的锁，通常叫 内部锁/Monitor 锁/Instrinsic Lock, 这把锁就是 监控锁。
synchronized 关键字修饰方法和代码块就是 同步方法
wait()/notify()/notifyAll() 方法构成监控条件(Monitor Condition)
在这里插入图片描述
线程和Monitor之间关系：
一个Monitor在某个时刻，只能被一个线程拥有，该线程就是Active Thread，
而其它线程都是Waiting Thread，分别在两个队列Entry Set和Wait Set里面等候。
在Entry Set中等待的线程状态是Waiting for monitor entry，
在Wait Set中等待的线程状态是in Object.wait()。

线程进入同步方法中：
为了继续执行临界区代码，线程必须获取 Monitor 锁。如果获取锁成功，将成为该监视者对象的拥有者。任一时刻内，监视者对象只属于一个活动线程（The Owner）
拥有监视者对象的线程可以调用 wait() 进入等待集合（Wait Set），同时释放监视锁，进入等待状态。
其他线程调用 notify() / notifyAll() 接口唤醒等待集合中的线程，这些等待的线程需要重新获取监视锁后才能执行 wait() 之后的代码。
同步方法执行完毕了，线程退出临界区，并释放监视锁。

进入区(Entrt Set):表示线程通过synchronized要求获取对象的锁。如果对象未被锁住,则迚入拥有者;否则则在进入区等待。一旦对象锁被其他线程释放,立即参与竞争。
拥有者(The Owner):表示某一线程成功竞争到对象锁。
等待区(Wait Set):表示线程通过对象的wait方法,释放对象的锁,并在等待区等待被唤醒。

线程调用修饰：
表示线程在方法调用时,额外的重要的操作，一般出现在线程内容中，用来协助分析线程的状态。
locked <对象地址> 对象名： 表示当前线程通过synchronized关键字成功获取到了目标对象的监视器，拥有了在临界区操作的权限，状态一般为runnable。注意对象锁是可重入的，所以这里有2次锁住了同一个对象。
waiting to lock <对象地址> 对象名：
表示当前线程未能通过synchronized关键字获取到目标对象的监视器，状态一般为blocked。
waiting on<对象地址> 对象名：
表示当前线程通过synchronized关键字成功获取到了目标对象的监视器，但调用了wait方法,进入对象的等待区等待。在调用栈顶出现,线程状态为WAITING或TIMED_WATING。
parking to wait for <对象地址> 对象名：
park是基本的线程阻塞原语,不通过监视器在对象上阻塞。随concurrent包会出现的新的机制,与synchronized体系不同，具体介绍可以看stackoverflow上的回答传送门。

系统线程状态：
出现在线程信息第一行的末尾。
deadlock：死锁线程
runnable：表示线程运行中或I/O等待，线程状态一般为RUNNABLE。
in Object.wait()：进入临界区之后，又调用了java.lang.Object.wait()方法等待,jvm线程状态一般为WAITING或TIMED_WAITING。
waiting for monitor entry：在等待进入一个临界区,线程状态一般状态为BLOCKED。
waiting on condition：线程正处于等待资源或等待某个条件的发生，具体的原因需要结合下面堆栈信息进行分析。
（1）如果堆栈信息明确是应用代码，则证明该线程正在等待资源，一般是大量读取某种资源且该资源采用了资源锁的情况下，线程进入等待状态，等待资源的读取，或者正在等待其他线程的执行等。
（2）如果发现有大量的线程都正处于这种状态，并且堆栈信息中得知正等待网络读写，这是可能因为网络阻塞导致线程无法执行。
（3）还有一种常见的情况是该线程在sleep，等待sleep的时间到了，将被唤醒。

JVM线程状态：
java.lang.Thread.State: RUNNABLE 线程运行中或I/O等待 方法调用-无
java.lang.Thread.State: BLOCKED (on object monitor) 等待进入一个临界区 方法调用-synchronized
java.lang.Thread.State: TIMED_WAITING (parking) 线程等待唤醒，并且设置等待时长 方法调用-LockSupport.parkNanos(等待时长)、LockSupport.parkUntil(等待时长)
java.lang.Thread.State: TIMED_WAITING (sleeping) 线程等待唤醒，并且设置等待时长 方法调用-Thread.sleep(等待时长)，Thread.join(等待时长)
java.lang.Thread.State: TIMED_WAITING (on object monitor) 线程在等待唤醒，并且设置等待时长 方法调用-Object.wait(等待时长)
java.lang.Thread.State: WAITING (parking) 线程等待唤醒，没有设置等待时长 方法调用-LockSupport.park()
java.lang.Thread.State: WAITING (on object monitor) 线程等待唤醒，并且没有设置等待时长 方法调用-Object.wait()
java.lang.Thread.State: WAITING (on object monitor) 线程等待唤醒，没有设置等待时长 方法调用-Thread.join()

jvm日志分析：
“ForkJoinPool.commonPool-worker-52”{线程名} #5688{线程ID} daemon prio=5{线程的优先级，取值范围为[1-10]，默认为 5，数值越低越有优先} os_prio=0{线程在操作系统中的优先级} tid=0x00007f31eb3f3800 nid=0xa8ec{Native thread ID，本地操作系统相关的线程id,对应JVM 虚拟机中线程映射在操作系统中的线程编号。（这个nid就是我们用top -Hp pid 查看到的线程号，不过要用printf "%x\n"转换一下进制）} waiting on condition [0x00007f31944d0000]{系统线程状态}
java.lang.Thread.State: WAITING (parking){JVM线程状态}
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000004706e6598> (a java.util.concurrent.ForkJoinPool)
at java.util.concurrent.ForkJoinPool.awaitWork(ForkJoinPool.java:1824)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1693)
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)

Locked ownable synchronizers:
- None

常见问题：
1）锁争用
如果出现大量的锁争用，可能是线程阻塞了！
#48线程获得了 <0x000000046b9b6078>对象的锁，进入了临界区；#49无法获取到锁，停留在Entry Set中，输出waiting to lock <0x000000046b9b6078>。
“hiveserver2-web-49-acceptor-2@23302924-ServerConnector@6d6d480c{HTTP/1.1,[http/1.1]}{0.0.0.0:10002}” #49 daemon prio=3 os_prio=0 tid=0x00007f31eaf33000 nid=0x6306 waiting for monitor entry [0x00007f31a3dfc000]
java.lang.Thread.State: BLOCKED (on object monitor) --JVM线程状态
at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:234)
- waiting to lock <0x000000046b9b6078> (a java.lang.Object)
at org.eclipse.jetty.server.ServerConnector.accept(ServerConnector.java:397)
at org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:601)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:748)

Locked ownable synchronizers:
- None
“hiveserver2-web-48-acceptor-1@580fe4f0-ServerConnector@6d6d480c{HTTP/1.1,[http/1.1]}{0.0.0.0:10002}” #48 daemon prio=3 os_prio=0 tid=0x00007f31eaf31800 nid=0x6305 runnable [0x00007f31a3efd000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)
at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)
- locked <0x000000046b9b6078> (a java.lang.Object)
at org.eclipse.jetty.server.ServerConnector.accept(ServerConnector.java:397)
at org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:601)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:748)

Locked ownable synchronizers:
- None

2）死锁
如果两个线程相互都被对方的线程锁锁住，这样就造成了死锁。
Thread1获取了<0x00000000d8251168>锁，等待<0x00000000d8251198>锁；Thread2获取了<0x00000000d8251198>锁，等待<0x00000000d8251168>锁。导致死锁！
“Thread2” daemon prio=5 tid=0x00007f1d3825f800 nid=0x2142 waiting for monitor entry [0x00007f1d16eeb000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.jvm.study.threaddump.deadlock.DeadLockMock$2.run(DeadLockMock.java:31)
- waiting to lock <0x00000000d8251168> (a java.lang.String)
- locked <0x00000000d8251198> (a java.lang.String)
“Thread1” daemon prio=5 tid=0x00007f1d3825e000 nid=0x2141 waiting for monitor entry [0x00007f1d16fec000]
ava.lang.Thread.State: BLOCKED (on object monitor)
at com.jvm.study.threaddump.deadlock.DeadLockMock$1.run(DeadLockMock.java:16)
- waiting to lock <0x00000000d8251198> (a java.lang.String)
- locked <0x00000000d8251168> (a java.lang.String)

3）等待区等待
JVM线程的状态是java.lang.Thread.State: TIMED_WAITING (on object monitor)，线程调用了java.lang.Object.wait(Native Method)方法而进入了等待状态。
"Wait Set"中等待的线程状态就是 in Object.wait()；
当线程获得了Monitor进入临界区之后，如果发现线程继续运行的条件没有满足，它就调用对象（通常是被synchronized的对象）的wait()方法，放弃了Monitor，进入"Wait Set"队列中。
只有当别的线程在该对象上调用了notify()或notifyAll()方法， “Wait Set” 队列中线程才得到机会去竞争，但是只有一个线程获得对象的 Monitor，从而恢复到运行态。
“IPC Client (2108708444) connection to IT-CDH-Node02/10.11.16.36:8020 from hive” #5681 daemon prio=5 os_prio=0 tid=0x00007f31ccf4a000 nid=0xa8e4 in Object.wait() [0x00007f319aa33000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at org.apache.hadoop.ipc.ClientConnection.waitForWork(Client.java:1017)
- locked <0x000000042b52dbf0> (a org.apache.hadoop.ipc.Client$Connection)
at org.apache.hadoop.ipc.ClientConnection.run(Client.java:1061)

Locked ownable synchronizers:
- None

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：/a/981055.html

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！

相关文章

Redis - 高可用实现方案解析：主从复制与哨兵监控

Redis - 高可用实现方案解析：主从复制与哨兵监控

文章目录 Pre概述Redis 高可用实现方案一、主从复制机制1.1 全量同步流程1.2 增量同步&#xff08;PSYNC&#xff09;流程 二、哨兵监控机制2.1 故障转移时序流程 三、方案对比与选型建议四、生产环境实践建议 Pre Redis-入门到精通 Redis进阶系列 Redis进阶 - Redis主从工作…
阅读更多...
栈和队列的模拟实现

栈和队列的模拟实现

文章目录 一. 回顾栈和队列二. stack的模拟实现stack.hstack.cpp 三. queue的模拟实现queue.htest.cpp 四. 了解dequeuevector和list都有各自的缺陷deque 总结 一. 回顾栈和队列 回顾一下栈和队列 栈&#xff1a;stack&#xff1a;后进先出 _ 队列&#xff1a;queue&#xf…
阅读更多...
【Linux】之【Bug】VMware 虚拟机开机 一直卡在黑屏左上角下划线闪烁界面

【Linux】之【Bug】VMware 虚拟机开机 一直卡在黑屏左上角下划线闪烁界面

解决 参考&#xff1a; 解决Ubuntu20.04 开机黑屏光标闪烁进不去系统 Centos根目录100%解决思路 当前界面 ctrlaltf3-f6 暂时进入终端界面 df -h 查看发现根目录 磁盘空间已满 执行命令 查看当前目录占用内存明细 sudo du -h -x --max-depth1清理无用的大内存文件 或者安装…
阅读更多...
【uniapp】离线打包uniapp为apk详细步骤

【uniapp】离线打包uniapp为apk详细步骤

先看效果 登录页面的图片由于来自于图鸟官网&#xff0c;这里没有显示。 离线打包uniapp为apk 运行环境&#xff1a;华为mate30&#xff0c;已经升级为鸿蒙系统。 参考文档 https://blog.csdn.net/xiaoyao_studio/article/details/144076431 https://juejin.cn/post/739…
阅读更多...
【通俗讲解电子电路】——从零开始理解生活中的电路(一)

【通俗讲解电子电路】——从零开始理解生活中的电路(一)

导言&#xff1a;电子电路为什么重要&#xff1f; ——看不见的“魔法”&#xff0c;如何驱动你的生活&#xff1f; 清晨&#xff0c;当你的手机闹钟响起时&#xff0c;你可能不会想到&#xff0c;是电子电路在精准控制着时间的跳动&#xff1b;当你用微波炉加热早餐时&#…
阅读更多...
Octave3D 关卡设计插件

Octave3D 关卡设计插件

课程参考链接 这位大佬有在视频合集中有详细的讲解&#xff0c;个人体验过&#xff0c;感觉功能很强大 https://www.bilibili.com/video/BV1Kq4y1C72P/?share_sourcecopy_web&vd_source0a41d8122353e3e841ae0a39908c2181 Prefab资源管理 第一步 在场景中创建一个空物体…
阅读更多...
通过多线程分别获取高分辨率和低分辨率的H264码流

通过多线程分别获取高分辨率和低分辨率的H264码流

目录 一.RV1126 VI采集摄像头数据并同时获取高分辨率码流和低分辨率码流流程 ​编辑 1.1初始化VI模块&#xff1a; 1.2初始化RGA模块&#xff1a; 1.3初始化高分辨率VENC编码器、 低分辨率VENC编码器&#xff1a; 1.4 VI绑定高分辨率VENC编码器&#xff0c;VI绑定RGA模块…
阅读更多...
【Python 数据结构 1.零基础复习】

【Python 数据结构 1.零基础复习】

目录 一、输入与输出 1.输入 2.格式化输出 二、数字与变量 1.字符串 & 整型 2.字符串 & 整型 & 浮点型 3.变量 练习 2235. 两整数相加 三、运算与操作 1.四则运算 练习 2769. 找出最大的可达成数字 3.取整与取余 练习 2651. 计算列车到站时间 ​编辑 四、真与假 1…
阅读更多...
21. 构造二叉树(卡码网)

21. 构造二叉树(卡码网)

21. 构造二叉树 find&#xff08;&#xff09;方法 在Python中&#xff0c;str.find(sub[, start[, end]]) 方法用于查找子字符串 sub 在字符串中首次出现的位置&#xff0c;返回其起始索引。如果未找到&#xff0c;返回 -1 class Tree:def __init__(self,valNone,leftNone,r…
阅读更多...
RocketMQ定时/延时消息实现机制

RocketMQ定时/延时消息实现机制

RocketMQ 的延迟消息是其核心特性之一&#xff0c;允许消息在指定延迟时间后才被消费者消费。 定时消息生命周期 一、延迟消息的核心机制 RocketMQ&#xff08;5.0之前&#xff09; 不支持任意时间精度的延迟&#xff0c;而是通过预定义的 延迟级别&#xff08;Delay Level&a…
阅读更多...
【编程题】7-3 树的同构

【编程题】7-3 树的同构

7-3 树的同构 1 题目原文2 思路解析3 代码实现4 总结 1 题目原文 题目链接&#xff1a;7-3 树的同构 给定两棵树 T 1 T_1 T1​ 和 T 2 T_2 T2​​。如果 T 1 T_1 T1​ 可以通过若干次左右孩子互换就变成 T 2 T_2 T2​&#xff0c;则我们称两棵树是“同构”的。例如图 1 1 …
阅读更多...
WebP2P技术在嵌入式设备中的应用：EasyRTC音视频通话SDK如何实现高效通信？

WebP2P技术在嵌入式设备中的应用：EasyRTC音视频通话SDK如何实现高效通信？

在数字化时代&#xff0c;实时通信技术&#xff08;RTC&#xff09;与人工智能&#xff08;AI&#xff09;的融合正在重塑各个行业的交互方式。从在线教育到远程医疗&#xff0c;从社交娱乐到企业协作&#xff0c;RTC的应用场景不断拓展。然而&#xff0c;传统的RTC解决方案往往…
阅读更多...
【前端】前端设计中的响应式设计详解

【前端】前端设计中的响应式设计详解

文章目录 前言一、响应式设计的定义与作用二、响应式设计的原则三、响应式设计的实现四、响应式设计的最佳实践总结 前言 在当今数字化时代&#xff0c;网站和应用程序需要适应各种设备&#xff0c;从桌面电脑到平板电脑和手机。响应式设计应运而生&#xff0c;成为一种可以适…
阅读更多...
【AVRCP】探寻AVRCP控制互操作性：连接、命令与设备交互

【AVRCP】探寻AVRCP控制互操作性：连接、命令与设备交互

AVRCP对于实现设备间的高效音频/视频控制至关重要。而控制互操作性要求作为AVRCP的核心部分&#xff0c;详细规定了设备在连接建立、命令传输等方面的具体操作。确保了不同设备之间能够实现无缝的远程控制。 一、AVCTP连接管理 1.1 AVCTP连接建立 发起者&#xff1a;AVCTP控制…
阅读更多...
LLM大型语言模型（一）

LLM大型语言模型（一）

1. 什么是 LLM&#xff1f; LLM&#xff08;大型语言模型&#xff09;是一种神经网络&#xff0c;专门用于理解、生成并对人类文本作出响应。这些模型是深度神经网络&#xff0c;通常训练于海量文本数据上&#xff0c;有时甚至覆盖了整个互联网的公开文本。 LLM 中的 “大” …
阅读更多...
2025国家护网HVV高频面试题总结来了04（题目+回答）

2025国家护网HVV高频面试题总结来了04（题目+回答）

网络安全领域各种资源&#xff0c;学习文档&#xff0c;以及工具分享、前沿信息分享、POC、EXP分享。不定期分享各种好玩的项目及好用的工具&#xff0c;欢迎关注。 一、HVV行动面试题分类 根据面试题的内容&#xff0c;我们将其分为以下几类&#xff1a; 漏洞利用与攻击技术 …
阅读更多...
解锁GPM 2.0「卡顿帧堆栈」｜代码示例与实战分析

解锁GPM 2.0「卡顿帧堆栈」｜代码示例与实战分析

每个游戏开发者都有一个共同的愿望&#xff0c;那就是能够在无需复现玩家反馈的卡顿现象时&#xff0c;快速且准确地定位卡顿的根本原因。为了实现这一目标&#xff0c;UWA GPM 2.0推出了全新功能 - 卡顿帧堆栈&#xff0c;旨在为开发团队提供高效、精准的卡顿分析工具。在这篇…
阅读更多...
【人工智能】蓝耘智算平台盛大发布DeepSeek满血版：开创AI推理体验新纪元

【人工智能】蓝耘智算平台盛大发布DeepSeek满血版：开创AI推理体验新纪元

&#x1f4dd;个人主页&#x1f339;&#xff1a;Eternity._ &#x1f339;&#x1f339;期待您的关注 &#x1f339;&#x1f339; ❀ 蓝耘智算平台 蓝耘智算平台核心技术与突破元生代推理引擎快速入门&#xff1a;三步调用大模型接口&#xff0c;OpenAI SDK无缝兼容实战用例文…
阅读更多...
用Python+Flask打造可视化武侠人物关系图生成器：从零到一的实战全记录

用Python+Flask打造可视化武侠人物关系图生成器：从零到一的实战全记录

用PythonFlask打造可视化武侠人物关系图生成器&#xff1a;从零到一的实战全记录 一、缘起&#xff1a;一个程序小白的奇妙探索之旅 作为一个接触Python仅13天的编程萌新&#xff0c;我曾以为开发一个完整的应用是遥不可及的事情。但在DeepSeek的帮助下&#xff0c;我竟用短短…
阅读更多...
Mac远程桌面软件哪个好用？

Mac远程桌面软件哪个好用？

远程桌面软件能帮助我们快速的远程控制另一台电脑&#xff0c;从而提供远程帮助&#xff0c;或者进行远程办公。那么&#xff0c;对macOS系统有什么好用的Mac远程桌面软件呢&#xff1f; 远程看看是一款操作简单、界面简洁的远程桌面软件&#xff0c;支持跨平台操作&#xff0…
阅读更多...
最新文章

Copyright @ 2022~2023