tomcat manage项目查看到连接池里有连接不能释放并且cpu负载过高

Acfe

先说结论
自己的代码一直不能执行完，可能原因是
1  代码有循环
2  代码有死锁（被阻塞)
4 当前线程请求的socket无响应，陷入无限等待，这时候该线程其实还是运行中。
欢迎补充其他原因

tomcat 的manage项目里显示 我们自己的项目里连接 竟然 这么久了还没执行完，
造成的后果就是一直站着tomcat的连接池的连接，


S50819745 ms0 KB0 KB10.0.6.153course.fanya.chaoxing.comGET /api/work? HTTP/1.0


从该信息目测问题有可能是 数据库死锁了引起了，毕竟这么久了 代码还没执行完，而且代码也只是简单的数据库查询。在数据库里看并没有发现死锁

用该命令查看 对应的进程 下面的线程运行情况

ps -mp 7839 -o THREAD,tid,time | sort -rn|more

USER     %CPU PRI SCNT WCHAN  USER SYSTEM   TID     TIME
root     44.5   -    - -         -      -     - 06:42:21
root      1.8  15    - futex_    -      -  7865 00:17:02
root     16.8  19    - -         -      -  8067 02:32:18
root      1.3  19    - futex_    -      -  7862 00:12:13


PRI (-c, -l)进程或内核线程的优先级。数字越大，优先级越低。


WCHAN（-l 标志）进程或内核线程为之等待或休眠的事件。对于内核线程，如果内核线程正在运行，该字段为空。对于进程，如果只有一个内核线程正在休眠，等待通道定义为该休眠内核线程的等待通道；否则显示一个星号。WCHAN（l 标志）进程等待的事件（系统中的一个地址）。选择一个符号对地址分类，除非请求数字输出。


发现第2个 tid号对应的线程已经执行了2个小时了，那就很有可能是刚才的有问题的那个tomcat线程了

把 7839 这个进程的 详细堆栈导出到 文件中，下载下来看看

命令  jstack -l 7839 > dumpcc.txt



jstack参数：
-l长列表. 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表


"http-8867-43" id=543 idx=0x2e0 tid=8067 prio=5 alive, native_waiting, daemon
    at pthread_cond_wait@@GLIBC_2.3.2+202(:0)@0x7f7d9d2565ba
    at eventTimedWaitNoTransitionImpl+71(event.c:90)@0x7f7d9c97a578
    at syncWaitForSignalNoTransition+65(synchronization.c:28)@0x7f7d9cb0d452
    at waitForLockIfNeededAndMarkAcquired+595(nativelock.c:163)@0x7f7d9ca9d894
    at nativeInnerLockNotLinked+126(nativelock.c:269)@0x7f7d9ca9dcdf
    at inner_native_lock+46(nativelock.c:442)@0x7f7d9ca9dd7f
    at gchreads_start_or_wait_for_gc+66(gcthreads.c:1030)@0x7f7d9c998973
    at gcThreadsStartOrWaitForGc+37(gcthreads.c:1128)@0x7f7d9c998d86
    at alloc_enqueue_allocation_and_wait_for_gc+270(allocator.c:201)@0x7f7d9c91741f
    at allocGetNewTla+152(allocator.c:655)@0x7f7d9c917649
    at RJNI_jrockit_vm_Allocator_getNewTla+61(rnimemsystem.c:57)@0x7f7d9cad707e
    at jrockit/vm/Allocator.getNewTla(JJ)V(Native Method)
    at jrockit/vm/Allocator.allocObjectOrArray(Allocator.java:354)[optimized]
    at java/util/regex/Pattern$BitClass.<init>(Pattern.java:2910)[optimized]
    at java/util/regex/Pattern.clazz(Pattern.java:2190)[inlined]
    at java/util/regex/Pattern.sequence(Pattern.java:1818)[optimized]
    at java/util/regex/Pattern.expr(Pattern.java:1752)[optimized]
    at java/util/regex/Pattern.group0(Pattern.java:2530)[optimized]
    at java/util/regex/Pattern.sequence(Pattern.java:1806)[optimized]
    at java/util/regex/Pattern.expr(Pattern.java:1752)[optimized]
    at java/util/regex/Pattern.group0(Pattern.java:2530)[optimized]
    at java/util/regex/Pattern.sequence(Pattern.java:1806)[optimized]
    at java/util/regex/Pattern.expr(Pattern.java:1752)[optimized]
    at java/util/regex/Pattern.compile(Pattern.java:1460)[optimized]
    at java/util/regex/Pattern.<init>(Pattern.java:1133)[inlined]
    at java/util/regex/Pattern.compile(Pattern.java:823)[inlined]
    at fanya/service/TestPaperService.isNumeric(TestPaperService.java:1163)[optimized]
    at fanya/service/TestPaperService.split(TestPaperService.java:1154)

看堆栈信息 里 是从TestPaperService.isNumeric 这行开始进入 正则的api，怀疑是自己代码有问题，就翻看isNumeric的实现，
发现 该方法内部有个 pattern.compile 还以为是高并发时，正则表达式太耗cpu或者 正则表达式本身有死循环那。就重写了该方法
并且把 pattern.compile 这一行代码当做成员变量而不是局部变量了。过了一周后更新到生产环境。本以为问题该解决了，但是发现问题还有，丝毫没有缓解的迹象
线程堆栈跟以前稍微有点不一样
  at pthread_cond_wait@@GLIBC_2.3.2+202(:0)@0x7f7d9d2565ba
    at eventTimedWaitNoTransitionImpl+71(event.c:90)@0x7f7d9c97a578
    at syncWaitForSignalNoTransition+65(synchronization.c:28)@0x7f7d9cb0d452
    at waitForLockIfNeededAndMarkAcquired+595(nativelock.c:163)@0x7f7d9ca9d894
    at nativeInnerLockNotLinked+126(nativelock.c:269)@0x7f7d9ca9dcdf
    at inner_native_lock+46(nativelock.c:442)@0x7f7d9ca9dd7f
    at gchreads_start_or_wait_for_gc+66(gcthreads.c:1030)@0x7f7d9c998973
    at gcThreadsStartOrWaitForGc+37(gcthreads.c:1128)@0x7f7d9c998d86
    at alloc_enqueue_allocation_and_wait_for_gc+270(allocator.c:201)@0x7f7d9c91741f
    at allocGetNewTla+152(allocator.c:655)@0x7f7d9c917649
    at RJNI_jrockit_vm_Allocator_getNewTla+61(rnimemsystem.c:57)@0x7f7d9cad707e
    at jrockit/vm/Allocator.getNewTla(JJ)V(Native Method)
    at jrockit/vm/Allocator.allocObjectOrArray(Allocator.java:354)[optimized]
    at java/util/regex/Pattern$BitClass.<init>(Pattern.java:2910)[optimized]
    at java/util/regex/Pattern.clazz(Pattern.java:2190)[inlined]
    at java/util/regex/Pattern.sequence(Pattern.java:1818)[optimized]
    at java/util/regex/Pattern.expr(Pattern.java:1752)[optimized]
    at java/util/regex/Pattern.group0(Pattern.java:2530)[optimized]
    at java/util/regex/Pattern.sequence(Pattern.java:1806)[optimized]
    at java/util/regex/Pattern.expr(Pattern.java:1752)[optimized]
    at java/util/regex/Pattern.group0(Pattern.java:2530)[optimized]
    at java/util/regex/Pattern.sequence(Pattern.java:1806)[optimized]
    at java/util/regex/Pattern.expr(Pattern.java:1752)[optimized]
    at java/util/regex/Pattern.compile(Pattern.java:1460)[optimized]
    at java/util/regex/Pattern.<init>(Pattern.java:1133)[inlined]
    at java/util/regex/Pattern.compile(Pattern.java:823)[inlined]
    at fanya/service/TestPaperService.split(TestPaperService.java:1154)


变成了从TestPaperService.split代码后直接到Pattern.compile方法，查看该方法发现 自己写的split方法里面有死循环。

ps:因为总想着是不是因为上面堆栈红色部分的那里是不是有bug，耽误了不少时间。