매일 업데이트
2022-11-26 09:40 23 min
기술 뉴스

스레드 덤프란 무엇이며 어떻게 분석합니까?

스레드 덤프 분석 및 활용법

스레드 덤프를 이해하고 분석하는 방법에 대해 자세히 알아보겠습니다. 스레드 덤프를 통해 문제점을 정확히 파악하고, 유용한 분석 도구들을 활용하는 방법을 살펴봅니다.

스레드란 무엇인가?

프로세스는 컴퓨터 메모리에 로드되어 실행되는 프로그램입니다. 프로세서는 이러한 프로그램을 실행하며, 프로세스는 변수, 파일 핸들, 프로그램 카운터, 레지스터, 신호 등 주요 정보를 포함하여 메모리에 상세히 기술됩니다.

프로세스는 여러 개의 가벼운 실행 단위인 스레드로 구성될 수 있습니다. 이는 병렬 처리를 통해 성능을 향상시키는 데 기여합니다. 프로세스 내의 모든 스레드는 메모리 공간을 공유하며 상호 의존적인 관계를 가집니다.

스레드 덤프란?

스레드 덤프는 실행 중인 프로세스 내 스레드의 현재 상태를 보여주는 스냅샷입니다. 이는 특정 시점에서 활성화된 모든 스레드의 정보, 스레드 상태 및 관련 데이터를 포함합니다.

현대 애플리케이션은 여러 스레드를 사용합니다. 각 스레드는 특정 작업을 수행하며, CPU 코어를 효율적으로 활용하여 애플리케이션 성능을 높입니다. 그러나 스레드가 서로 조화를 이루지 못해 교착 상태를 유발할 수도 있습니다. 따라서, 문제가 발생했을 때 스레드 덤프를 통해 스레드 상태를 검사하는 것이 중요합니다.

Java 스레드 덤프

JVM 스레드 덤프는 특정 시점에서 프로세스를 구성하는 모든 스레드의 상태를 보여주는 목록입니다. 각 스레드의 스택 정보와 스택 추적을 포함하며, 평문으로 저장하여 나중에 검토할 수 있습니다. 스레드 덤프 분석은 다음과 같은 목적으로 사용됩니다.

  • JVM 성능 최적화
  • 애플리케이션 성능 향상
  • 교착 상태, 스레드 경쟁 등 문제 진단

스레드 덤프 생성 방법

스레드 덤프를 생성하는 방법은 다양합니다. 다음은 JVM 기반 도구들이며, Java 설치 폴더 내 명령줄 도구 또는 GUI 도구를 통해 실행할 수 있습니다.

1. jStack

jStack은 가장 간단하게 스레드 덤프를 생성할 수 있는 도구입니다. JVM과 함께 제공되며, 명령줄에서 프로세스 ID (PID)를 사용하여 실행됩니다. PID는 `jps` 명령을 통해 확인할 수 있습니다.

`jps -l` 명령은 실행 중인 모든 Java 프로세스의 ID를 나열합니다.

Windows 환경 

C:Program FilesJavajdk1.8.0_171bin>jps -l
47172 portal
6120 sun.tools.jps.Jps
C:Program FilesJavajdk1.8.0_171bin>

Linux 환경 

[[email protected] ~]# jps -l
1088 /opt/keycloak/jboss-modules.jar
26680 /var/lib/jenkins/workspace/kyc/kyc/target/kyc-1.0.jar
7193 jdk.jcmd/sun.tools.jps.Jps
2058 /usr/share/jenkins/jenkins.war
11933 /var/lib/jenkins/workspace/admin-portal/target/portal-1.0.jar
[[email protected] ~]#

`jps -l` 명령은 실행 중인 Java 프로세스의 로컬 VM ID와 애플리케이션 이름을 각각의 열에 표시합니다. 이제 `jstack -l [PID]` 명령을 사용하여 스레드 덤프를 생성하고, 필요에 따라 파일로 저장할 수 있습니다. 예를 들어, `jstack -l 26680`과 같이 사용할 수 있습니다. 

[[email protected] ~]# jstack -l 26680
2020-06-27 06:04:53
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.221-b11 mixed mode):

"Attach Listener" #16287 daemon prio=9 os_prio=0 tid=0x00007f0814001800 nid=0x4ff2 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"logback-8" #2316 daemon prio=5 os_prio=0 tid=0x00007f07e0033000 nid=0x4792 waiting on condition [0x00007f07baff8000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000006ca9a1fc0> (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)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - None

"logback-7" #2315 daemon prio=5 os_prio=0 tid=0x00007f07e0251800 nid=0x4791 waiting on condition [0x00007f07bb0f9000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000006ca9a1fc0> (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)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - None

2. jvisualvm

Jvisualvm은 Java 애플리케이션 문제 해결, 모니터링 및 프로파일링을 위한 GUI 도구입니다. Java 설치 폴더의 /bin 디렉터리에서 시작할 수 있으며, 직관적인 인터페이스를 제공합니다. 특정 프로세스의 스레드 덤프를 캡처하려면 해당 프로세스를 마우스 오른쪽 버튼으로 클릭하고 컨텍스트 메뉴에서 "스레드 덤프"를 선택합니다.

3. jcmd

jcmd는 JDK와 함께 제공되는 명령줄 유틸리티로, JVM에 진단 명령을 전송하는 데 사용됩니다. 로컬 시스템에서 실행 중인 Java 애플리케이션에만 작동합니다. `jcmd [PID] Thread.print` 명령을 사용하여 특정 프로세스의 스레드 덤프를 가져올 수 있습니다.

다음은 jcmd 사용 예시입니다.

`jcmd 28036 스레드.프린트` 

C:Program FilesJavajdk1.8.0_171bin>jcmd 28036 Thread.print
28036:
2020-06-27 21:20:02
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.171-b11 mixed mode):

"Bundle File Closer" #14 daemon prio=5 os_prio=0 tid=0x0000000021d1c000 nid=0x1d4c in Object.wait() [0x00000000244ef000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Unknown Source)
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:403)
        - locked <0x000000076f380a88> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread)
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:339)

"Active Thread: Equinox Container: 0b6cc851-96cd-46de-a92b-253c7f7671b9" #12 prio=5 os_prio=0 tid=0x0000000022e61800 nid=0xbff4 waiting on condition [0x00000000243ee000]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x000000076f388188> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(Unknown Source)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Unknown Source)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

"Service Thread" #10 daemon prio=9 os_prio=0 tid=0x0000000021a7b000 nid=0x2184 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #9 daemon prio=9 os_prio=2 tid=0x00000000219f5000 nid=0x1300 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #8 daemon prio=9 os_prio=2 tid=0x00000000219e0000 nid=0x48f4 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #7 daemon prio=9 os_prio=2 tid=0x00000000219df000 nid=0xb314 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x00000000219db800 nid=0x2260 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x00000000219d9000 nid=0x125c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x00000000219d8000 nid=0x834 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000001faf3000 nid=0x36c0 in Object.wait() [0x0000000021eae000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076f390180> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(Unknown Source)
        - locked <0x000000076f390180> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(Unknown Source)
        at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000005806000 nid=0x13c0 in Object.wait() [0x00000000219af000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076f398178> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Unknown Source)
        at java.lang.ref.Reference.tryHandlePending(Unknown Source)
        - locked <0x000000076f398178> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)

"main" #1 prio=5 os_prio=0 tid=0x000000000570e800 nid=0xbf8 runnable [0x0000000000fec000]
   java.lang.Thread.State: RUNNABLE
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(Unknown Source)
        at java.util.zip.ZipFile.<init>(Unknown Source)
        at java.util.zip.ZipFile.<init>(Unknown Source)
        at org.eclipse.osgi.framework.util.SecureAction.getZipFile(SecureAction.java:307)
        at org.eclipse.osgi.storage.bundlefile.ZipBundleFile.getZipFile(ZipBundleFile.java:136)
        at org.eclipse.osgi.storage.bundlefile.ZipBundleFile.lockOpen(ZipBundleFile.java:83)
        at org.eclipse.osgi.storage.bundlefile.ZipBundleFile.getEntry(ZipBundleFile.java:290)
        at org.eclipse.equinox.weaving.hooks.WeavingBundleFile.getEntry(WeavingBundleFile.java:65)
        at org.eclipse.osgi.storage.bundlefile.BundleFileWrapper.getEntry(BundleFileWrapper.java:55)
        at org.eclipse.osgi.storage.BundleInfo$Generation.getRawHeaders(BundleInfo.java:130)
        - locked <0x000000076f85e348> (a java.lang.Object)
        at org.eclipse.osgi.storage.BundleInfo$CachedManifest.get(BundleInfo.java:599)
        at org.eclipse.osgi.storage.BundleInfo$CachedManifest.get(BundleInfo.java:1)
        at org.eclipse.equinox.weaving.hooks.SupplementerRegistry.addSupplementer(SupplementerRegistry.java:172)
        at org.eclipse.equinox.weaving.hooks.WeavingHook.initialize(WeavingHook.java:138)
        at org.eclipse.equinox.weaving.hooks.WeavingHook.start(WeavingHook.java:208)
        at org.eclipse.osgi.storage.FrameworkExtensionInstaller.startActivator(FrameworkExtensionInstaller.java:261)
        at org.eclipse.osgi.storage.FrameworkExtensionInstaller.startExtensionActivators(FrameworkExtensionInstaller.java:198)
        at org.eclipse.osgi.internal.framework.SystemBundleActivator.start(SystemBundleActivator.java:112)
        at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:815)
        at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:808)
        at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:765)
        at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1005)
        at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.initWorker(EquinoxBundle.java:190)
        at org.eclipse.osgi.container.SystemModule.init(SystemModule.java:99)
        at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.init(EquinoxBundle.java:272)
        at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.init(EquinoxBundle.java:257)
        at org.eclipse.osgi.launch.Equinox.init(Equinox.java:171)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:316)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:251)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:661)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:597)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1476)

"VM Thread" os_prio=2 tid=0x000000001fae8800 nid=0x32cc runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000005727800 nid=0x3264 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000000005729000 nid=0xbdf4 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000000000572a800 nid=0xae6c runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x000000000572d000 nid=0x588 runnable

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x000000000572f000 nid=0xac0 runnable

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x0000000005730800 nid=0x380 runnable

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x0000000005733800 nid=0x216c runnable

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x0000000005734800 nid=0xb930 runnable

"VM Periodic Task Thread" os_prio=2 tid=0x0000000021a8d000 nid=0x2dcc waiting on condition

JNI global references: 14


C:Program FilesJavajdk1.8.0_171bin>

4. JMC (Java Mission Control)

JMC는 JDK와 함께 제공되는 오픈 소스 GUI 도구로, Java 애플리케이션 데이터를 수집하고 분석하는 데 사용됩니다. Java 설치의 /bin 폴더에서 실행할 수 있으며, 로컬 또는 원격 시스템에서 실행 중인 Java 프로세스 목록을 표시합니다. 특정 프로세스를 선택한 후, "비행 기록 시작"을 통해 데이터를 수집하고 "스레드" 탭에서 스레드 덤프를 확인할 수 있습니다.

5. jconsole

jconsole은 Java 관리 확장 도구로, 애플리케이션 관리 및 모니터링에 사용됩니다. JMX 에이전트에 대한 다양한 작업을 수행할 수 있으며, 실행 중인 프로그램의 스택 추적을 감지하고 분석할 수 있습니다. jconsole은 Java 설치의 /bin 폴더에서 실행할 수 있습니다. GUI 도구를 통해 실행 중인 Java 프로세스에 연결하면 각 스레드의 스택 추적을 검사할 수 있습니다. 스레드 탭에서 실행 중인 모든 스레드를 확인하고, 교착 상태를 감지하려면 창 오른쪽 하단에 있는 "교착 상태 감지"를 클릭합니다.

6. ThreadMxBean

ThreadMXBean은 `java.lang.Management` 패키지에 속하는 인터페이스로, Java 가상 머신의 스레드 시스템 관리를 위한 인터페이스입니다. 주로 교착 상태에 빠진 스레드를 감지하고 세부 정보를 얻는 데 사용됩니다. `ManagementFactory.getThreadMXBean()` 메서드를 사용하여 `ThreadMXBean` 인터페이스의 인스턴스를 얻을 수 있습니다. 또한, 데몬 및 비데몬 라이브 스레드의 수를 반환할 수 있습니다. 

private static String getThreadDump (boolean lockMonitors, boolean lockSynchronizers) {
    StringBuffer threadDump = new StringBuffer (System.lineSeparator ());
    ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean ();
    for (ThreadInfo threadInfo : threadMXBean.dumpAllThreads (lockMonitors, lockSynchronizers)) {
        threadDump.append (threadInfo.toString ());
    }
    return threadDump.toString ();
}

스레드 덤프 수동 분석

스레드 덤프 분석은 다중 스레드 프로세스의 문제를 정확히 찾아내는 데 유용합니다. 교착 상태, 잠금 경합, 과도한 CPU 사용률과 같은 문제들을 스레드 덤프의 상태를 시각화하여 해결할 수 있습니다. 스레드 덤프를 분석한 후 각 스레드의 상태를 수정하여 애플리케이션의 성능을 최적화할 수 있습니다.

예를 들어, 프로세스가 CPU를 많이 사용하는 경우, CPU를 가장 많이 사용하는 스레드를 찾을 수 있습니다. 해당 스레드의 LWP 번호를 16진수로 변환한 후, 스레드 덤프에서 동일한 `nid` 값을 가진 스레드를 찾아 문제를 파악할 수 있습니다.

다음 명령을 사용하여 스레드의 프로세스 ID를 확인할 수 있습니다.

`ps -mo pid,lwp,stime,time,cpu -C java` 

[[email protected] ~]# ps -mo pid,lwp,stime,time,cpu -C java
       PID        LWP         STIME           TIME              %CPU
26680               -         Dec07          00:02:02           99.5
         -       10039        Dec07          00:00:00           0.1
         -       10040        Dec07          00:00:00           95.5

이제 스레드 덤프를 분석해 보겠습니다. `jstack -l 26680` 명령으로 얻은 프로세스 26680의 스레드 덤프입니다. 

[[email protected] ~]# jstack -l 26680
2020-06-27 09:01:29
<strong>Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.221-b11 mixed mode):</strong>

"Attach Listener" #16287 daemon prio=9 os_prio=0 tid=0x00007f0814001800 nid=0x4ff2 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

.
.
.
.
.
.
.
"<strong>Reference Handler</strong>" #2 daemon prio=10 os_prio=0 tid=0x00007f085814a000 nid=0x6840 in Object.wait() [0x00007f083b2f1000]
   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 <0x00000006c790fbd0> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

   Locked ownable synchronizers:
        - None

"VM Thread" os_prio=0 tid=0x00007f0858140800 nid=0x683f runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f0858021000 nid=0x683b runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f0858022800 nid=0x683c runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f0858024800 nid=0x683d runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f0858026000 nid=0x683e runnable

"VM Periodic Task Thread" os_prio=0 tid=0x00007f08581a0000 nid=0x6847 waiting on condition

JNI global references: 1553

스레드 덤프는 많은 정보를 포함하지만, 차근차근 분석하면 이해하기 쉽습니다. 첫 번째 줄은 덤프가 생성된 시간과 사용된 JVM 정보를 보여줍니다. 다음으로 스레드 목록이 나타나며, 첫 번째는 `ReferenceHandler` 스레드입니다.

`2020-06-27 09:01:29
전체 스레드 덤프 Java HotSpot(TM) 64비트 서버 VM(25.221-b11 혼합 모드):`

차단된 스레드 분석

스레드 덤프를 분석하면 애플리케이션 성능 저하의 원인이 되는 `BLOCKED` 상태의 스레드를 감지할 수 있습니다. 이러한 스레드가 획득하려는 잠금 및 현재 잠금을 보유하고 있는 스레드를 확인하여 문제를 해결할 수 있습니다. 

[[email protected] ~]# jstack -l 26680
.
.
.
.
" DB-Processor-13" daemon prio=5 tid=0x003edf98 nid=0xca waiting for monitor entry [0x000000000825f000]
java.lang.Thread.State: <strong>BLOCKED</strong> (on object monitor)
                at beans.ConnectionPool.getConnection(ConnectionPool.java:102)
                - waiting to lock <0xe0375410> (a beans.ConnectionPool)
                at beans.cus.ServiceCnt.getTodayCount(ServiceCnt.java:111)
                at beans.cus.ServiceCnt.insertCount(ServiceCnt.java:43)
"DB-Processor-14" daemon prio=5 tid=0x003edf98 nid=0xca waiting for monitor entry [0x000000000825f020]
java.lang.Thread.State: <strong>BLOCKED</strong> (on object monitor)
                at beans.ConnectionPool.getConnection(ConnectionPool.java:102)
                - waiting to lock <0xe0375410> (a beans.ConnectionPool)
                at beans.cus.ServiceCnt.getTodayCount(ServiceCnt.java:111)
                at beans.cus.ServiceCnt.insertCount(ServiceCnt.java:43)
.
.
.
.

교착 상태 분석

스레드 덤프를 분석하는 또 다른 주요 용도는 교착 상태를 감지하는 것입니다. 교착 상태는 여러 스레드가 서로 필요한 자원을 잠그고 있어 아무 스레드도 진행할 수 없는 상황을 의미합니다. 스레드 덤프의 마지막 섹션에서 교착 상태에 대한 정보를 다음과 같이 확인할 수 있습니다. 

"Thread-0":
waiting to lock monitor 0x00000250e4982480 (object 0x00000000894465b0, a java.lang.Object),
which is held by "Thread-1"
"Thread-1":
waiting to lock monitor 0x00000250e4982380 (object 0x00000000894465a0, a java.lang.Object),
which is held by "Thread-0"
.
.
.
"Thread-0":
at Deadlocked
저자
김민준
Korea

기술 트렌드와 실용적인 팁을 전하는 लेखक입니다.

관련 기사
2025-12-26
2026년 클라우드 보안 - 모든 기업이 반드시 바로잡아야 할 것들
휴대폰 알림 소리와 함께 시작되는 악몽이 있습니다. 노출된 AWS S3 버킷에서 고객 데이터가 유출되어 규제 당국의 조사를 받고, 올해 초 중견 소매업체에 480만 달러의 벌금이 부과되었습니다. 급하게 배포하느라 공개 액세스를 켜둔 단순한 실수에서...
2025-11-25
2025년 최고의 guest posting sites & guest post marketplace 랭킹 가이드
해외 SEO, 링크 빌딩, 브랜드 인지도를 동시에 키우고 싶다면 개별 블로그에 하나씩 연락하는 방식만으로는 한계가 있습니다. 대신 전 세계 퍼블리셔와 광고주가 한 곳에 모여 거래하는 guest posting sites 와 guest post...
2025-11-11
한국시장에서존재감강화, 지역채택급증속성장가속화
대한민국, 서울 — 2025 년 10 월 . 한국의 디지털 자산 시장이 놀라운 깊이와 속도로 성장하고 있다. 최근 규제 기관의 공시 자료에 따르면, 대한민국 내 약 1 만 800 명 이상이 10 억 원 ( 약 74 만 달러 ) 이상의 디지털 자산을...
2025-10-19
노벨상 수상자 양젠닝, 103세로 별세…물리학계 큰 별 지다
## 천닝 양, 103세로 별세… 현대 물리학 발전에 지대한 공헌 20세기 물리학의 거장 천닝 양(Chen Ning Yang)이 베이징에서 103세의 나이로 별세했다. 양의 획기적인 연구, 특히 소립자 이해에 대한 그의 공헌은 기초 물리학 을...
이전 기사
Google 크롬 상태 잘못된 이미지 해시 오류 수정
다음 기사
iPhone 손전등이 작동하지 않는 문제를 해결하는 12가지 방법