0

here is the thread dump file . it is a tomcat service . i found many thread time_waited on logging . but no actual log was wrote.

i've used jvisualvm to monitor the full-gc , but gc was normal .

i can't get any useful information out of this thread dump . there are possibilities that cpu are stuck in a while loop . but there's no evidence shown in this thread dump .

if you need any other information , i will provide it , really wanted to figure this out . :D

thread dump

Adams.H
  • 1,603
  • 4
  • 20
  • 29
  • A thread in the timed waiting state doesn’t consume CPU. You have to look for the *runnable* threads. After all, there are more than hundred runnable threads in your list of over thousand threads. That suggests that there *is* some activity and it’s rather unlikely that all of them are stuck in an erroneous loop. – Holger Aug 21 '18 at 11:23
  • i've connected the jvm with jvisualvm ,but no suspicious cpu event was found – Adams.H Aug 22 '18 at 02:03
  • thread dump file is already deleted – Yuriy Alevohin Dec 21 '18 at 10:42
  • I'm seeing the same thing on JDK 10 - one core used constantly, but no Java threads runnable (as evidenced by internal profiling as well as VisualVM). I filed a bug report with Oracle (Bug ID 9061722, waiting for approval). – Stefan Reich Jul 24 '19 at 20:06

2 Answers2

0

here is the gc log , the eden space was filled quickly ,but it's wired that the from & to space were both empty before and after the minor gc , the old generation is also full , maybe objects too many and can't filled in the young generation.

enter image description here

Adams.H
  • 1,603
  • 4
  • 20
  • 29
  • The problem is the full old generation, or simply not enough memory in general. So there’s a full gc running in short intervals, only to reclaim 1% of the Eden space, just enough to let your application continue, but requiring the next full gc within less than a second. – Holger Aug 22 '18 at 06:05
0

I have analysis your thread-dump file with fastthread.io and thre result link is:thread_dump_file_analysis_result

There are some problems for this thread dump:

  • too many thread is created, 1199. This is a high thread count! It can result in java.lang.OutOfMemoryError: Unable to create new native thread.
  • the gc.log also come to this. The program is creating the thread constantly and make the fgc happen —— When the thread object is too big to created in from or to space, so the garbage collector try allocate the object in old space, but the fgc has been full.
javadu
  • 21
  • 3