jstack 堆栈情况

最新推荐文章于 2023-01-04 21:08:28 发布
最新推荐文章于 2023-01-04 21:08:28 发布
阅读量338 收藏
点赞数
CC 4.0 BY-SA版权
文章标签： 开发工具 java python
原文链接：https://my.oschina.net/u/1862478/blog/1928094

2019独角兽企业重金招聘Python工程师标准>>> hot3.png

jstack用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。 

jstack命令主要用来查看Java线程的调用堆栈的，可以用来分析线程问题（如死锁）。

线程状态

NEW                 未启动的。不会出现在Dump中。
RUNNABLE      在虚拟机内执行的。运行中状态，可能里面还能看到locked字样，表明它获得了某把锁。
BLOCKED        受阻塞并等待监视器锁。被某个锁(synchronizers)給block住了。
WATING         无限期等待另一个线程执行特定操作。等待某个condition或monitor发生，一般停留在park(), wait(), sleep(),join() 等语句里。
TIMED_WATING    有时限的等待另一个线程的特定操作。和WAITING的区别是wait() 等语句加上了时间限制 wait(timeout)。
TERMINATED        已退出的。

Monitor

Monitor是 Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 Class的锁。每一个对象都有，也仅有一个 monitor。

Entrt Set: 线程通过synchronized要求获取对象的锁。如果对象未被锁住,则进入 (The Owner)；否则在 Entrt Set 等待。一旦对象锁被其他线程释放,立即参与竞争。

The Owner：表示某一线程成功竞争到对象锁。

Wait Set：线程通过对象的wait方法,释放对象的锁,并在等待区等待被唤醒。

一个 Monitor在某个时刻，只能被一个线程拥有，该线程就是“Active Thread”，而其它线程都是“Waiting Thread”，分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在“Entry Set”中等待的线程是“Waiting for monitor entry”，而在“Wait Set”中等待的线程是 “in Object.wait()”。
“Entry Set”里面的线程，称被 synchronized保护起来的代码段为临界区。当一个线程申请进入临界区时，它就进入了 “Entry Set”队列。对应的 code就像：
synchronized(obj) {
.........
}

调用修饰

表示线程在方法调用时,额外的重要的操作。线程Dump分析的重要信息。修饰上述的方法调用。
locked <地址> 目标：使用synchronized申请对象锁成功,监视器的拥有者。
waiting to lock <地址> 目标：使用synchronized申请对象锁未成功,在 Entry Set 等待。
waiting on <地址> 目标：使用synchronized申请对象锁成功后,释放锁 并在 Wait Set 等待。
parking to wait for <地址> 目标

locked:

通过synchronized关键字,成功获取到对象的锁,成为监视器的Owner,在临界区内操作。对象锁是可以线程重入的。

	- locked <0x00000007a379d9d8> (a org.apache.cxf.interceptor.ServiceInvokerInterceptor$2)
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
	- locked <0x00000007a379da00> (a org.apache.cxf.phase.PhaseInterceptorChain)

 

waiting to lock:

通过synchronized关键字,没有获取到对象的锁,线程在监视器的Entry Set 等待。在调用栈顶出现,线程状态为Blocked。

"qtp294375100-61 Acceptor5 SelectChannelConnector@10.151.15.103:19990" #61 prio=5 os_prio=0 tid=0x00007f300c001000 nid=0x2b64e waiting for monitor entry [0x00007f30c346b000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:233)
	- waiting to lock <0x00000006c2eb7dc8> (a java.lang.Object)
	at org.eclipse.jetty.server.nio.SelectChannelConnector.accept(SelectChannelConnector.java:109)
	at org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:938)

 

waiting on :

通过synchronized关键字,成功获取到对象的锁后,调用了wait方法,进入对象的 Wait Set 等待。

在调用栈顶出现,线程状态为WAITING或TIMED_WATING。

"Abandoned connection cleanup thread" #23 daemon prio=5 os_prio=0 tid=0x00007f30286cc800 nid=0x2b5eb in Object.wait() [0x00007f30ca647000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000006c004a890> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
	- locked <0x00000006c004a890> (a java.lang.ref.ReferenceQueue$Lock)

 

parking to wait for :

park是基本的线程阻塞原语,不通过监视器在对象上阻塞。随concurrent包会出现的新的机制,与synchronized体系不同。

"http-bio-18880-exec-5655" #243691 daemon prio=5 os_prio=0 tid=0x00007f2e24099800 nid=0x633 waiting on condition [0x00007f30b3073000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006c4a21e58> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)

 

线程动作

线程状态产生的原因
runnable ：状态一般为RUNNABLE。
in Object.wait()：等待区等待,状态为WAITING或TIMED_WAITING。
waiting for monitor entry：进入区等待,状态为BLOCKED。
waiting on condition:等待区等待、被park。
sleeping:休眠的线程,调用了Thread.sleep()。

使用示例：

jstack  pid 
 
dump 文件里，值得关注的线程状态有：
死锁，Deadlock（重点关注） 
执行中，Runnable   
等待资源，Waiting on condition（重点关注） 
等待获取监视器，Waiting on monitor entry（重点关注）
暂停，Suspended
对象等待中，Object.wait() 或 TIMED_WAITING
阻塞，Blocked（重点关注）  
停止，Parked

实例1  waiting to lock 和 BLOCKED

"qtp294375100-44 Acceptor2 SelectChannelConnector@10.151.15.103:19990" #44 prio=5 os_prio=0 tid=0x00007f3029abc800 nid=0x2b63f waiting for monitor entry [0x00007f30c3dfa000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:233)
	- waiting to lock <0x00000006c2eb7dc8> (a java.lang.Object)
	at org.eclipse.jetty.server.nio.SelectChannelConnector.accept(SelectChannelConnector.java:109)
	at org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:938)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
	at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
	- None

1）线程状态是 Blocked，阻塞状态。说明线程等待资源超时！

2）“ waiting to lock <0x00000006c2eb7dc8>”，线程在等待给这个 0x00000006c2eb7dc8 地址上锁（trying to obtain  0x00000006c2eb7dc8 lock）。

3）在 dump 日志里查找字符串 0x00000006c2eb7dc8，发现有大量线程都在等待给这个地址上锁。如果能在日志里找到谁获得了这个锁（如locked < 0x00000006c2eb7dc8>），就可以顺藤摸瓜了。

4）“waiting for monitor entry”说明此线程通过 synchronized(obj) {……} 申请进入了临界区，从而进入了“Entry Set”队列，但该 obj 对应的 monitor 被其他线程拥有，所以本线程在 Entry Set 队列中等待。

5）第一行里，""qtp294375100-44 Acceptor2 SelectChannelConnector@10.151.15.103:19990""是 Thread Name 。tid指Java Thread id。nid指native线程的id。prio是线程优先级。[0x00000006c2eb7dc8]是线程栈起始地址。

Dump文件中的线程状态含义及注意事项

  • Deadlock：死锁线程，一般指多个线程调用间，进入相互资源占用，导致一直等待无法释放的情况。
  • Runnable：一般指该线程正在执行状态中，该线程占用了资源，正在处理某个请求，有可能正在传递SQL到数据库执行，有可能在对某个文件操作，有可能进行数据类型等转换。
  • Waiting on condition：等待资源，或等待某个条件的发生。具体原因需结合 stacktrace来分析。
    • 如果堆栈信息明确是应用代码，则证明该线程正在等待资源。一般是大量读取某资源，且该资源采用了资源锁的情况下，线程进入等待状态，等待资源的读取。
    • 又或者，正在等待其他线程的执行等。
    • 如果发现有大量的线程都在处在 Wait on condition，从线程 stack看，正等待网络读写，这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。
      • 一种情况是网络非常忙，几乎消耗了所有的带宽，仍然有大量数据等待网络读写；
      • 另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。
    • 另外一种出现 Wait on condition的常见情况是该线程在 sleep，等待 sleep的时间到了时候，将被唤醒。
  • Blocked：线程阻塞，是指当前线程执行过程中，所需要的资源长时间等待却一直未能获取到，被容器的线程管理器标识为阻塞状态，可以理解为等待资源超时的线程。
  • Waiting for monitor entry 和 in Object.wait()：Monitor是 Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 Class的锁。每一个对象都有，也仅有一个 monitor。每个 Monitor在某个时刻，只能被一个线程拥有，该线程就是 “Active Thread”，而其它线程都是 “Waiting Thread”，分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitor entry”，而在 “Wait Set”中等待的线程状态是 “in Object.wait()”。

 

示例 2  Waiting on condition 和 TIMED_WAITING

"Log4j2-TF-4-6f71ad04-100" #243665 prio=5 os_prio=0 tid=0x00007f2ff800a000 nid=0x5ae waiting on condition [0x00007f30ba8b2000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006c1a4c110> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
	- None

1）“TIMED_WAITING (parking)”中的 timed_waiting 指等待状态，但这里指定了时间，到达指定的时间后自动退出等待状态；parking指线程处于挂起中。
2）“waiting on condition”需要与堆栈中的“parking to wait for  <0x00000006c1a4c110>(a java.util.concurrent.SynchronousQueue$TransferStack)”结合来看。首先，本线程肯定是在等待某个条件的发生，来把自己唤醒。其次，SynchronousQueue 并不是一个队列，只是线程之间移交信息的机制，当我们把一个元素放入到 SynchronousQueue 中时必须有另一个线程正在等待接受移交的任务，因此这就是本线程在等待的条件。

 

示例3    in Object.wait() 和 TIMED_WAITING

RMI RenewClean-[172.16.5.19:28475]" daemon prio=10 tid=0x0000000041428800 nid=0xb09 in Object.wait() [0x00007f34f4bd0000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000aa672478> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
- locked <0x00000000aa672478> (a java.lang.ref.ReferenceQueue$Lock)
at sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:516)
at java.lang.Thread.run(Thread.java:662)

1）“TIMED_WAITING (on object monitor)”，本例中 是因为本线程调用了 java.lang.Object.wait(long timeout) 而进入等待状态。

2）“Wait Set”中等待的线程状态就是“ in Object.wait() ”。当线程获得了 Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入 “Wait Set”队列。只有当别的线程在该对象上调用了 notify() 或者 notifyAll() ，“ Wait Set”队列中线程才得到机会去竞争，但是只有一个线程获得对象的 Monitor，恢复到运行态。 

3）RMI RenewClean 是 DGCClient 的一部分。DGC 指的是 Distributed GC，即分布式垃圾回收。

4）请注意，是先 locked <0x00000000aa672478>，后 waiting on <0x00000000aa672478>，之所以先锁再等同一个对象，请看下面它的代码实现：

static private class  Lock { };
private Lock lock = new Lock();
public Reference<? extends T> remove(long timeout)
{
    synchronized (lock) {
        Reference<? extends T> r = reallyPoll();
        if (r != null) return r;
        for (;;) {
            lock.wait(timeout);
            r = reallyPoll();
            ……
       }
}

即，线程的执行中，先用 synchronized 获得了这个对象的 Monitor（对应于  locked <0x00000000aa672478> ）；当执行到 lock.wait(timeout);，线程就放弃了 Monitor 的所有权，进入“Wait Set”队列（对应于  waiting on <0x00000000aa672478> ）。

5）从堆栈信息看，是正在清理 remote references to remote objects ，引用的租约到了，分布式垃圾回收在逐一清理。

-----------------------------------------------------------------------------------------------------------------

问题排查

1. top 某进程

 

2.找出该进程内最耗费CPU的线程

这里我们分析 172148 这个线程，这个线程是属于 172116 这个进程的。

 

4. jstack查找这个线程的信息 

 

****************************************************************************

1、线程Dump的分析

入手点

进入区等待

"qtp774527142-50 Acceptor3 SelectChannelConnector@127.0.0.1:19990" #50 prio=5 os_prio=0 tid=0x00007f5e7d834000 nid=0x1414f waiting for monitor entry [0x00007f5e43cf8000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:234)
	- waiting to lock <0x0000000642f86378> (a java.lang.Object)
	at org.eclipse.jetty.server.nio.SelectChannelConnector.accept(SelectChannelConnector.java:109)
	at org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:938)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
	at java.lang.Thread.run(Thread.java:745)

线程状态BLOCKED,线程动作waiting for monitor entry,调用修饰waiting to lock总是一起出现。表示在代码级别已经存在冲突的调用。必然有问题的代码,需要尽可能减少其发生。

 

同步块阻塞

一个线程锁住某对象,大量其他线程在该对象上等待。

转载于:https://my.oschina.net/u/1862478/blog/1928094

Java的 jstack堆栈分析
learn_cat的博客
06-13 626
java的jstack的堆栈信息，直接肉眼难以查看定位，发现了一个在线工具，可以方便地进行线程定位。而且，附带有gc的排查，基本能用。
JVM故障分析及性能优化系列之一：jstack定位线程堆栈信息
PYROMANIA
05-14 1179
前一段时间上线的系统升级之后，出现了严重的高CPU的问题，于是开始了一系列的优化处理之中，现在将这个过程做成一个系列的文章。more。
线程的几个状态
weixin_34235135的博客
01-04 158
Runnable：一般指该线程正在执行状态中，该线程占用了资源，正在处理某个请求，例如有可能在对某个文件操作，有可能进行数据类型等转换。 Waiting on condition：等待资源，或等待某个条件的发生。具体原因需结合stacktrace来分析。 如果堆栈信息明确是应用代码，则证明该线程正在等待资源。一般是大量...
jstack命令案例分析：对wait的线程没有调用notify()导致程序无法停止
学亮编程手记
04-30 730
对wait的线程没有调用notify()导致的结果就是程序无法停止。 o.notify(); //必须，否则无法停止程序 public class T06_00_sync_wait_notify { public static void main(String[] args) { final Object o = new Object(); char[...
13.7.深入理解jstack日志，线程的状态
涂作权的博客
08-14 1万+
13.7.深入理解jstack日志 转自：https://blog.csdn.net/iteye_5603/article/details/82652200 在分析线上问题时常使用到jstack 命令将当时Java应用程序的线程堆栈dump出来。 面对jstack 日志，我们如何查看？ 首先要清楚线程的状态 线程的状态有：new、runnable、running、waiting、timed_waiting、blocked、dead 线程状态变迁图： 各状态说明： New: 当线程对象创建时存在的状态，此时
【JVM故障问题排查心得】「线程诊断系列」通过jstack线程状态分析虚拟机线程问题指南
世界上并没有完美的程序，但是我们并不因此而沮丧，因为写程序就是一个不断追求完美的过程。
01-04 1540
学习研究thread dump文件是一种很不错的能力哦，因为它可以帮助我们在危急关头去解决和分析问题，接下来，就让我们开始分析和研究一下jstack dump文件吧。
jstack 命令的使用和堆栈分析
weixin_30342209的博客
03-22 831
原文：https://www.cnblogs.com/kongzhongqijing/articles/3630264.html 一、介绍 jstack 是 Java 虚拟机自带的一种堆栈跟踪工具。jstack 用于打印出给定的 java 进程 ID 或 core file 或远程调试服务的 Java 堆栈信息。 如果是在 64 位机器上，需要指定选项 "-J-d64"，Windows 的 ...
jstack 堆栈 分析
最新发布
08-22
它通常用于诊断Java应用程序中的死锁、性能瓶颈或者异常情况，因为堆栈跟踪可以帮助开发者了解当前哪些线程处于阻塞状态以及它们的执行上下文。 当你运行 `jstack` 命令，它会生成每个线程的堆栈跟踪（StackTrace）...
jstack 脚本 自动日志_jstack 堆栈日志分析
weixin_35933239的博客
02-17 340
一、线程的状态线程间的状态转换：1.新建(new)：新创建了一个线程对象。2.可运行(runnable)：线程对象创建后，其他线程(比如main线程)调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取cpu 的使用权 。3.运行(running)：可运行状态(runnable)的线程获得了cpu 时间片(timeslice) ，执行程序代码。4.阻塞(blo...
jstack 堆栈信息分析
07-08
使用jstack命令获取的堆栈信息可以帮助您分析Java应用程序中的线程情况和问题。以下是一些常见的堆栈信息分析方法： 1. 查看死锁情况：在堆栈信息中搜索关键字"Deadlock"，如果存在死锁，将会显示相关的线程和锁...
java多线程使用不当造成的问题
关注系统性能调优
06-06 1万+
下面的thread dump是在CPU使用高的情况下采集的jstack的数据。 "pool-19-thread-50" prio=10 tid=0x00007fd1b8001000 nid=0x11bb2 runnable [0x00007fd41f018000]    java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrap
在Linux环境搭建Java版Minecraft(我的世界)服务器
Meow_wu的博客
09-27 7468
文章目录前言一、帮助轻松开服的工具1.Xshell2.XFTP二、开服步骤1.准备一个可以满足你需要的Linux服务器2.安装工具3.连接服务器4.配置服务器（确保你已经完成第三步，成功连接上了服务器）1）安装Java（如果你的服务器上已经安装过了，请忽略）2）关闭防火墙3）安装screen5.装载Minecraft服务器后言 前言 本篇内容是为了一些首次尝试使用Linux进行开服的小白服主，提供一些技术上的帮助。因此，将在这里展示较为简单方便，通俗易懂的开服过程以供参考。 一、帮助轻松开服的工具 1.
2021-02-02
zjj198925的博客
02-02 744
1、描述现象 es出现了线程卡死不消费的现象，如下图，除非重新发布，或者重启机器才会继续消费数据 2、日志分析 排查了很久的日志，发现ES在调用bulk或者mget的时候，日志打印了调用bulk或mget前的日志，执行结果日志缺没有显示，且日志停止时间和曲线停止消费时间完全吻合，日志截图如下 2018-10-25 02:35:02,313 [pool-43-thread-1] INFO [HANDLER_LOG] - [SingleTabBulkRetryHandler][2099][handl
java导致系统满载_排查解决java进程占用系统内存高
weixin_32390647的博客
02-26 786
使用top命令查看系统资源的使用情况top获取java的PID或者jps -ljps -v通过命令查看进程的线程情况**ps p pid-L -o pcpu,pmem,pid,tid,time,tname,cmd**找到以下进程中，CPU利用率比较高的线程号TID(十进制数),此处为12394接下来就可以通过jstack查看内存使用的堆栈。将获取的线程号PID(十进制数)转换成十六进制printf...
java堆栈常用排查指令
Less Is More
04-19 2714
java 异常排查四板斧 1、查看java 堆栈线程信息 说明 jstack命令打印指定Java进程、核心文件或远程调试服务器的Java线程的Java堆栈跟踪信息。 对于每个Java框架，完整的类名，方法名， 字节码索引(BCI)和行号(如果有的话)被打印出来。 使用-m选项，jstack命令打印程序中所有线程的Java和本机帧 计数器(PC)。 对于每个本机帧，当可用时，将打印离PC最近的本机符号。 c++乱码的名字不会被修改。 要demangle c++名称，输出这个 命令可以管道到c++filt。 当
原来jdk自带了这么好玩的工具 ＞ 使用 jstack定位死循环
叶新东老师的博客
07-15 3573
什么是jstack jstack的主要作用是查看或者导出java线程的堆栈信息(快照)；用于堆栈跟踪，当我们使用jstack命令时，它会将指定进程内的所有线程中方法的调用栈打印出来。 线程快照是java虚拟机内每一个线程正在执行的方法堆栈的集合，生成线程快照的主要目的是用于定位线程出现问题的位置；常见的问题有 响应时间长 线程死锁 死循环 当线程停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道线程的执行过程中在后台做了哪些事，在等待哪些资源造成的卡顿。 使用方法 命令格式 jstack
jetty的SelectChannelConnector分析
fjs的专栏
11-04 3268
jetty的NioConnector之SelectChannelConnector的实现与运行原理。。。
java.io.IOException 断开的管道 解决方法 ClientAbortException: java.io.IOException: Broken pipe
热门推荐
zqz_zqz的博客
08-17 20万+
今天公司技术支持的童鞋报告一个客户的服务不工作了，紧急求助，于是远程登陆上服务器排查问题。 查看采集数据的tomcat日志，习惯性的先翻到日志的最后去查看有没有异常的打印，果然发现了好几种异常信息，但是最多还是这个： 24-Nov-2016 09:54:21.116 SEVERE [http-nio-8081-Acceptor-0] org.apache.tomcat.uti...
Error-NioEndpoint-打开文件过多
不知名的博客
01-25 1254
1. 场景： 使用javacv将rtsp流转为flv,服务跑几天后报错。 2022-01-20 09:32:41.214 [http-nio-9145-Acceptor-0] ERROR org.apache.tomcat.util.net.NioEndpoint - Socket accept failed java.io.IOException: 打开的文件过多 at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) ~
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值