JVM 调优

最新推荐文章于 2023-11-08 15:26:52 发布

原创最新推荐文章于 2023-11-08 15:26:52 发布 · 1k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#java

java 专栏收录该内容

28 篇文章

订阅专栏

本文详细介绍了jstack在Java进程分析中的应用，教你如何使用jstack诊断线程阻塞、死锁和性能瓶颈，通过实例演示了如何查看线程状态和调用栈，以及如何调整并发策略以提高性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

jstack使用

1.总述

jstack是jvm虚拟机自带的一种堆栈分析工具，用于打印出给定的java进程或者core file或者远程调试服务的堆栈信息等。主要分为两个功能如下：
a.针对活着的进程做本地的或者远程的线程的dump
b.针对core文件做线程dump
jstack命令可以快捷的定位线程出现长时间停顿的原因，如线程间死锁，死循环，请求外部的资源导致长时间的等待等。

jstack的基本用法

我们在控制台输入 jstack -help，打印如下信息：

[root@izvwwt3webhi84z ~]# jstack -help
Usage:
    jstack [-l] <pid>
        (to connect to running process)
    jstack -F [-m] [-l] <pid>
        (to connect to a hung process)
    jstack [-m] [-l] <executable> <core>
        (to connect to a core file)
    jstack [-m] [-l] [server_id@]<remote server IP or hostname>
        (to connect to a remote debug server)
Options:
    -F  to force a thread dump. Use when jstack <pid> does not respond (process is hung)
    -m  to print both java and native frames (mixed mode)
    -l  long listing. Prints additional information about locks
    -h or -help to print this help message

可以看到有3个参数可供我们的各种需求。
-F 执行线程转储
-m 打印java和本地帧
-l打印列表信息，包括锁相关的信息

线程状态

想要通过jstack查看线程的情况的话，有必要了解线程的几种执行状态，下面这些状态是我们通过jstack查看线程堆栈信息时可能会看到的：
RUNNABLE,在虚拟机内执行的。运行中状态，可能里面还能看到locked字样，表明它获得了某把锁。
BLOCKED,受阻塞并等待监视器锁。被某个锁(synchronizers)給block住了。
WATING,无限期等待另一个线程执行特定操作。等待某个condition或monitor发生，一般停留在park(), wait(), sleep(),join() 等语句里。
TIMED_WATING,有时限的等待另一个线程的特定操作。和WAITING的区别是wait() 等语句加上了时间限制 wait(timeout)。
TERMINATED,已退出的

调用修饰

表示线程在调用的时候的额外的重要的操作，线程dump分析的重要信息
locked <地址> 使用synchronized申请对象锁成功后，监视器的拥有者
waiting to lock <地址>使用synchronized申请锁对象失败，在进入区等待
waiting on <地址>使用synchronized申请锁对象成功后，在等待区等待
parking to wait for <地址>调用了park方法

线程动作

in object wait() <地址>等待区等待，线程状态可为waiting或者timed_waiting

Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f86a4102000 nid=0xac7 in Object.wait() [0x00007f868edf4000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:502)
    at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
    - locked <0x00000000ea2e6d10> (a java.lang.ref.Reference$Lock)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

runnable运行状态
waiting on condition <地址>线程状态可为runnable，waiting(parking)或者timed_waiting (sleeping)

logback-1" #10 daemon prio=5 os_prio=0 tid=0x00007f86a42db000 nid=0xacf waiting on condition [0x00007f868c3e1000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000000ea203980> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)

C1 CompilerThread1  daemon prio=9 os_prio=0 tid=0x00007f86a413e000 nid=0xacb waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

使用实例

jstack查看线程具体在做什么，查看哪些线程在长时间占用cpu，尽快发现问题和解决问题
a.用top命令查看进程消耗cpu的情况，查看消耗高的进程来分析。

top - 23:03:18 up 48 days,  2:07,  2 users,  load average: 0.00, 0.01, 0.05
Tasks:  99 total,   1 running,  98 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.8 us,  0.7 sy,  0.0 ni, 98.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  8010460 total,   459580 free,  5867196 used,  1683684 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  1809732 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND    
18602 root      20   0 2808772 281956  13840 S   0.7  3.5   6:22.06 java       
27484 root      20   0 2947772 417468  14152 S   0.7  5.2   2:52.65 java       
32473 root      20   0 2872624 332384  13944 S   0.7  4.1  37:09.33 java       
 1243 mysql     20   0 1621728 363796   5944 S   0.3  4.5  29:41.37 mysqld     
 1512 root      20   0 3644460 366936  13808 S   0.3  4.6  21:18.60 java

b.我们可以看到18602的进程消耗cpu比价高，于是可以分析该进程下的线程的使用情况。在控制台输入 top -Hp 18602，如下所示

18603 root    15   0 1807m 630m 9492 S  1.3  4.0   0:05.12 java                                                                                           
20503 root  15   0 1360m 560m 9176 S  0.3  3.6   0:46.72 java

我们来分析18603线程，并且注意18603的线程是属于18602进程的。
输入jstack 18602 | grep -A 10 [线程的16进制]即jstack 18602 | grep -A 10 48ab,得到如下结果

[root@izvwwt3webhi84z ~]# jstack 18602 | grep -A 10 48ab
"DestroyJavaVM" #28 prio=5 os_prio=0 tid=0x00007f119cb24000 nid=0x48ab waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"New I/O server boss #4" #24 daemon prio=5 os_prio=0 tid=0x00007f119d1c6000 nid=0x48c4 runnable [0x00007f1158912000]
   java.lang.Thread.State: RUNNABLE
    at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
    at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
    at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
    at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
    - locked <0x00000000f28b7538> (a sun.nio.ch.Util$3)
    - locked <0x00000000f28b7548> (a java.util.Collections$UnmodifiableSet)

于是我们可以根据堆栈信息来分析问题了。
这里附上进制转换的网站https://www.sojson.com/hexconvert.html

作者：是王威啊
链接：https://www.jianshu.com/p/dee9d02f11b3
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

多线程

类似多进程方式，但是针对一个连接启动一个线程。

优点：相对多进程方式，会节约一些资源，会更加高效一些。

缺点：相对多进程方式，增加了编程的复杂度，因为需要考虑数据同步和锁保护。另外一个进程中不能启动太多的线程。在Linux系统下线程在系统内部其实就是进程，线程调度按照进程调度的方式去执行的。

应用：类似于多进程方式，适用于少量的客户端的时候。

Select+多线程

有一个线程专门用于监听端口，accept返回之后就把这个描述符放入描述符集合 fd中，一个线程用select去轮训描述符集合，在有数据的连接上接收数据，另外一个线程专门发送数据。当然也可以接收和发送用一个线程。描述符可以设置成非阻塞模式，也可以设置成阻塞模式。通常连接设置成非阻塞模式，发送线程独立出来。

优点：相对前几种模式，这种模式大大提高了并发量。

缺点：系统一般实现描述符集合是采用一个大数组，每次调用select的时候都会轮询这个描述符数组，当连接数很多的时候就会导致效率下降。连接数在1000以上时候效率会下降到不能接受。

应用：目前windows 和一般的Unix上的tcp并发都采用select方式，应该说应用还是很广泛的。

epoll方式

在Linux2.6版本之后，增加了epoll。具体的使用是：一个线程专门进行端口监听，accept接收到连接的时候，把该连接设置成非阻塞模式，把 epoll事件设置成边缘触发方式，加入到epoll管理。接收线程阻塞在epoll的等待事件函数。另外一个线程专门用于数据发送。

优点：由于epoll的实现方式先进，所以这种方式可以大规模的实现并发。我们现在的应用在一个3年前的dell的pc server可以实现2万个连接的并发，性能也是很好的。

缺点：由于涉及了线程和非阻塞，所以会导致编码的复杂度增大一些。这种方式只适用于Linux 2.6内核以后。

注意：

1) 如果把epoll事件设置成水平触发效率就下降到类似采用select的水平。

2) Unix系统下有单个进程打开的描述符数目限制，还有系统内打开的描述符数目限制。系统内打开的描述符数目限制由软硬限制两个。硬限制是根据机器的配置而不同。软限制可以更改，但是必须小于系统的硬限制。在suse Linux下，可以在root用户下，通过ulimit -n 数目去修改这个限制。

应用： Linux下大规模的tcp并发。

配置开发支持高并发TCP连接的Linux应用程序全攻略

修改用户进程可打开文件数限制

在Linux平台上，无论编写客户端程序还是服务端程序，在进行高并发TCP连接处理时，最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制(这是因为系统为每个TCP连接都要创建一个socket句柄，每个socket句柄同时也是一个文件句柄)。可使用ulimit命令查看系统允许当前用户进程打开的文件数限制：

[speng@as4 ~]$ ulimit -n

1024

这表示当前用户的每个进程最多允许同时打开1024个文件，这1024个文件中还得除去每个进程必然打开的标准输入，标准输出，标准错误，服务器监听 socket，进程间通讯的unix域socket等文件，那么剩下的可用于客户端socket连接的文件数就只有大概1024-10=1014个左右。也就是说缺省情况下，基于Linux的通讯程序最多允许同时1014个TCP并发连接。

对于想支持更高数量的TCP并发连接的通讯处理程序，就必须修改Linux对当前用户的进程同时打开的文件数量的软限制(soft limit)和硬限制(hardlimit)。其中软限制是指Linux在当前系统能够承受的范围内进一步限制用户同时打开的文件数；硬限制则是根据系统硬件资源状况(主要是系统内存)计算出来的系统最多可同时打开的文件数量。通常软限制小于或等于硬限制。

修改上述限制的最简单的办法就是使用ulimit命令：

[speng@as4 ~]$ ulimit -n <file_num>

上述命令中，在<file_num>中指定要设置的单一进程允许打开的最大文件数。如果系统回显类似于“Operation notpermitted”之类的话，说明上述限制修改失败，实际上是因为在<file_num>中指定的数值超过了Linux系统对该用户打开文件数的软限制或硬限制。因此，就需要修改Linux系统对用户的关于打开文件数的软限制和硬限制。

第一步，修改/etc/security/limits.conf文件，在文件中添加如下行：

speng soft nofile 10240

speng hard nofile 10240

其中speng指定了要修改哪个用户的打开文件数限制，可用'*'号表示修改所有用户的限制；soft或hard指定要修改软限制还是硬限制；10240则指定了想要修改的新的限制值，即最大打开文件数(请注意软限制值要小于或等于硬限制)。修改完后保存文件。

第二步，修改/etc/pam.d/login文件，在文件中添加如下行：

session required /lib/security/pam_limits.so

这是告诉Linux在用户完成系统登录后，应该调用pam_limits.so模块来设置系统对该用户可使用的各种资源数量的最大限制(包括用户可打开的最大文件数限制)，而pam_limits.so模块就会从/etc/security/limits.conf文件中读取配置来设置这些限制值。修改完后保存此文件。

第三步，查看Linux系统级的最大打开文件数限制，使用如下命令：

[speng@as4 ~]$ cat /proc/sys/fs/file-max

12158

这表明这台Linux系统最多允许同时打开(即包含所有用户打开文件数总和)12158个文件，是Linux系统级硬限制，所有用户级的打开文件数限制都不应超过这个数值。通常这个系统级硬限制是Linux系统在启动时根据系统硬件资源状况计算出来的最佳的最大同时打开文件数限制，如果没有特殊需要，不应该修改此限制，除非想为用户级打开文件数限制设置超过此限制的值。修改此硬限制的方法是修改/etc/rc.local脚本，在脚本中添加如下行：

echo 22158 > /proc/sys/fs/file-max

这是让Linux在启动完成后强行将系统级打开文件数硬限制设置为22158。修改完后保存此文件。

完成上述步骤后重启系统，一般情况下就可以将Linux系统对指定用户的单一进程允许同时打开的最大文件数限制设为指定的数值。如果重启后用 ulimit-n命令查看用户可打开文件数限制仍然低于上述步骤中设置的最大值，这可能是因为在用户登录脚本/etc/profile中使用ulimit -n命令已经将用户可同时打开的文件数做了限制。由于通过ulimit-n修改系统对用户可同时打开文件的最大数限制时，新修改的值只能小于或等于上次 ulimit-n设置的值，因此想用此命令增大这个限制值是不可能的。所以，如果有上述问题存在，就只能去打开/etc/profile脚本文件，在文件中查找是否使用了ulimit-n限制了用户可同时打开的最大文件数量，如果找到，则删除这行命令，或者将其设置的值改为合适的值，然后保存文件，用户退出并重新登录系统即可。

通过上述步骤，就为支持高并发TCP连接处理的通讯处理程序解除关于打开文件数量方面的系统限制。

修改网络内核对TCP连接的有关限制

在Linux上编写支持高并发TCP连接的客户端通讯处理程序时，有时会发现尽管已经解除了系统对用户同时打开文件数的限制，但仍会出现并发TCP连接数增加到一定数量时，再也无法成功建立新的TCP连接的现象。出现这种现在的原因有多种。

第一种原因可能是因为Linux网络内核对本地端口号范围有限制。此时，进一步分析为什么无法建立TCP连接，会发现问题出在connect()调用返回失败，查看系统错误提示消息是“Can't assign requestedaddress”。同时，如果在此时用tcpdump工具监视网络，会发现根本没有TCP连接时客户端发SYN包的网络流量。这些情况说明问题在于本地Linux系统内核中有限制。其实，问题的根本原因在于Linux内核的TCP/IP协议实现模块对系统中所有的客户端TCP连接对应的本地端口号的范围进行了限制(例如，内核限制本地端口号的范围为1024~32768之间)。当系统中某一时刻同时存在太多的TCP客户端连接时，由于每个TCP客户端连接都要占用一个唯一的本地端口号(此端口号在系统的本地端口号范围限制中)，如果现有的TCP客户端连接已将所有的本地端口号占满，则此时就无法为新的TCP客户端连接分配一个本地端口号了，因此系统会在这种情况下在connect()调用中返回失败，并将错误提示消息设为“Can't assignrequested address”。有关这些控制逻辑可以查看Linux内核源代码，以linux2.6内核为例，可以查看tcp_ipv4.c文件中如下函数：

static int tcp_v4_hash_connect(struct sock *sk)

请注意上述函数中对变量sysctl_local_port_range的访问控制。变量sysctl_local_port_range的初始化则是在tcp.c文件中的如下函数中设置：

void __init tcp_init(void)

内核编译时默认设置的本地端口号范围可能太小，因此需要修改此本地端口范围限制。

第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：

net.ipv4.ip_local_port_range = 1024 65000

这表明将系统对本地端口范围限制设置为1024~65000之间。请注意，本地端口范围的最小值必须大于或等于1024；而端口范围的最大值则应小于或等于65535。修改完后保存此文件。

第二步，执行sysctl命令：

[speng@as4 ~]$ sysctl -p

如果系统没有错误提示，就表明新的本地端口范围设置成功。如果按上述端口范围进行设置，则理论上单独一个进程最多可以同时建立60000多个TCP客户端连接。

第二种无法建立TCP连接的原因可能是因为Linux网络内核的IP_TABLE防火墙对最大跟踪的TCP连接数有限制。此时程序会表现为在 connect()调用中阻塞，如同死机，如果用tcpdump工具监视网络，也会发现根本没有TCP连接时客户端发SYN包的网络流量。由于 IP_TABLE防火墙在内核中会对每个TCP连接的状态进行跟踪，跟踪信息将会放在位于内核内存中的conntrackdatabase中，这个数据库的大小有限，当系统中存在过多的TCP连接时，数据库容量不足，IP_TABLE无法为新的TCP连接建立跟踪信息，于是表现为在connect()调用中阻塞。此时就必须修改内核对最大跟踪的TCP连接数的限制，方法同修改内核对本地端口号范围的限制是类似的：

第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：

net.ipv4.ip_conntrack_max = 10240

这表明将系统对最大跟踪的TCP连接数限制设置为10240。请注意，此限制值要尽量小，以节省对内核内存的占用。

第二步，执行sysctl命令：

[speng@as4 ~]$ sysctl -p

如果系统没有错误提示，就表明系统对新的最大跟踪的TCP连接数限制修改成功。如果按上述参数进行设置，则理论上单独一个进程最多可以同时建立10000多个TCP客户端连接。

使用支持高并发网络I/O的编程技术

在Linux上编写高并发TCP连接应用程序时，必须使用合适的网络I/O技术和I/O事件分派机制。

可用的I/O技术有同步I/O，非阻塞式同步I/O(也称反应式I/O)，以及异步I/O。在高TCP并发的情形下，如果使用同步I/O，这会严重阻塞程序的运转，除非为每个TCP连接的I/O创建一个线程。但是，过多的线程又会因系统对线程的调度造成巨大开销。因此，在高TCP并发的情形下使用同步 I/O是不可取的，这时可以考虑使用非阻塞式同步I/O或异步I/O。非阻塞式同步I/O的技术包括使用select()，poll()，epoll等机制。异步I/O的技术就是使用AIO。

从I/O事件分派机制来看，使用select()是不合适的，因为它所支持的并发连接数有限(通常在1024个以内)。如果考虑性能，poll()也是不合适的，尽管它可以支持的较高的TCP并发数，但是由于其采用“轮询”机制，当并发数较高时，其运行效率相当低，并可能存在I/O事件分派不均，导致部分 TCP连接上的I/O出现“饥饿”现象。而如果使用epoll或AIO，则没有上述问题(早期Linux内核的AIO技术实现是通过在内核中为每个 I/O请求创建一个线程来实现的，这种实现机制在高并发TCP连接的情形下使用其实也有严重的性能问题。但在最新的Linux内核中，AIO的实现已经得到改进)。

综上所述，在开发支持高并发TCP连接的Linux应用程序时，应尽量使用epoll或AIO技术来实现并发的TCP连接上的I/O控制，这将为提升程序对高并发TCP连接的支持提供有效的I/O保证。