垃圾收集器线程似乎饿死等待 Heap_lock。这是 GC 线程的堆栈跟踪
+ 5480 _pthread_start (in libsystem_pthread.dylib) + 168 [0x7fff9255191a]
+ 5480 _pthread_body (in libsystem_pthread.dylib) + 131 [0x7fff9255199d]
+ 5480 java_start(Thread*) (in libjvm.dylib) + 246 [0x110e82cd6]
+ 5480 YieldingFlexibleGangWorker::loop() (in libjvm.dylib) + 419 [0x110fbf8fb]
+ 5480 Monitor::wait(bool, long, bool) (in libjvm.dylib) + 375 [0x110e5c859]
+ 5480 Monitor::IWait(Thread*, long) (in libjvm.dylib) + 168 [0x110e5c5f0]
+ 5480 ParkCommon(ParkEvent*, long) (in libjvm.dylib) + 42 [0x110e5bd1a]
+ 5480 os::PlatformEvent::park() (in libjvm.dylib) + 192 [0x110e7ea72]
+ 5480 _pthread_cond_wait (in libsystem_pthread.dylib) + 767 [0x7fff92552728]
+ 5480 __psynch_cvwait (in libsystem_kernel.dylib) + 10 [0x7fff98080db6]
我的 Java 应用程序产生了大约 300 个线程。他们也会挨饿。这是一个堆栈跟踪示例：
+ 5480 java_lang_String::create_from_str(char const*, Thread*) (in libjvm.dylib) + 59 [0x110cf1ab9]
+ 5480 java_lang_String::basic_create(int, Thread*) (in libjvm.dylib) + 38 [0x110cef8a0]
+ 5480 InstanceKlass::allocate_instance(Thread*) (in libjvm.dylib) + 31 [0x110cbd93f]
+ 5480 CollectedHeap::obj_allocate(KlassHandle, int, Thread*) (in libjvm.dylib) + 38 [0x110cbff8a]
+ 5480 CollectedHeap::common_mem_allocate_noinit(KlassHandle, unsigned long, Thread*) (in libjvm.dylib) + 140 [0x110ab2484]
+ 5480 GenCollectorPolicy::mem_allocate_work(unsigned long, bool, bool*) (in libjvm.dylib) + 475 [0x110b9f313]
+ 5480 Monitor::lock(Thread*) (in libjvm.dylib) + 132 [0x110e5c4e6]
+ 5480 Monitor::ILock(Thread*) (in libjvm.dylib) + 310 [0x110e5c3dc]
+ 5480 ParkCommon(ParkEvent*, long) (in libjvm.dylib) + 42 [0x110e5bd1a]
+ 5480 os::PlatformEvent::park() (in libjvm.dylib) + 192 [0x110e7ea72]
+ 5480 _pthread_cond_wait (in libsystem_pthread.dylib) + 767 [0x7fff92552728]
+ 5480 __psynch_cvwait (in libsystem_kernel.dylib) + 10 [0x7fff98080db6]
运行我的应用程序几个小时后，饥饿就开始了。
我尝试了三个收集器：使用默认设置的 UseG1GC、UseParallelGC 和 UseConcMarkSweepGC，但仍然感到饥饿（没有尝试过串行 GC）。
我在 OSX 10.11.5 上使用 Java 1.8.0_92（构建 1.8.0_92-b14，Java HotSpot(TM) 64 位服务器 VM，构建 25.92-b14，混合模式）。
有足够的堆空间Xmx6G；我没有看到完整的 GC。我将 GC 线程 XX:VMThreadStackSize 的堆栈增加到 10MB，但得到了同样的饥饿。我还使用了较旧的 Java，同样饥饿。我没有看到任何致命错误日志 ( http://www.oracle.com/technetwork/java/javase/felog-138657.html )。
请建议如何调试这种饥饿。
2016 年 6 月 19 日更新：
我按堆栈跟踪对挂起的线程进行了分组，您可以看到
挂在 GangWorker::loop()
5347 Thread_669608
+ 5347 thread_start (in libsystem_pthread.dylib) + 13 [0x7fff930c3351]
+ 5347 _pthread_start (in libsystem_pthread.dylib) + 168 [0x7fff930c591a]
+ 5347 _pthread_body (in libsystem_pthread.dylib) + 131 [0x7fff930c599d]
+ 5347 java_start(Thread*) (in libjvm.dylib) + 246 [0x112485bbe]
+ 5347 GangWorker::loop() (in libjvm.dylib) + 179 [0x1125c194f]
+ 5347 Monitor::wait(bool, long, bool) (in libjvm.dylib) + 375 [0x11245f639]
+ 5347 Monitor::IWait(Thread*, long) (in libjvm.dylib) + 168 [0x11245f3d0]
+ 5347 ParkCommon(ParkEvent*, long) (in libjvm.dylib) + 42 [0x11245eafa]
+ 5347 os::PlatformEvent::park() (in libjvm.dylib) + 192 [0x11248195a]
+ 5347 _pthread_cond_wait (in libsystem_pthread.dylib) + 767 [0x7fff930c6728]
+ 5347 __psynch_cvwait (in libsystem_kernel.dylib) + 10 [0x7fff8dbbcdb6]
挂在 ConcurrentG1RefineThread::wait_for_completed_buffers()
5347 Thread_669627
+ 5347 thread_start (in libsystem_pthread.dylib) + 13 [0x7fff930c3351]
+ 5347 _pthread_start (in libsystem_pthread.dylib) + 168 [0x7fff930c591a]
+ 5347 _pthread_body (in libsystem_pthread.dylib) + 131 [0x7fff930c599d]
+ 5347 java_start(Thread*) (in libjvm.dylib) + 246 [0x112485bbe]
+ 5347 ConcurrentG1RefineThread::run() (in libjvm.dylib) + 90 [0x1121c054e]
+ 5347 ConcurrentG1RefineThread::wait_for_completed_buffers() (in libjvm.dylib) + 65 [0x1121c08e5]
+ 5347 Monitor::wait(bool, long, bool) (in libjvm.dylib) + 375 [0x11245f639]
+ 5347 Monitor::IWait(Thread*, long) (in libjvm.dylib) + 168 [0x11245f3d0]
+ 5347 ParkCommon(ParkEvent*, long) (in libjvm.dylib) + 42 [0x11245eafa]
+ 5347 os::PlatformEvent::park() (in libjvm.dylib) + 192 [0x11248195a]
+ 5347 _pthread_cond_wait (in libsystem_pthread.dylib) + 767 [0x7fff930c6728]
+ 5347 __psynch_cvwait (in libsystem_kernel.dylib) + 10 [0x7fff8dbbcdb6]
编译器线程挂起
5347 Thread_669680: Java: C2 CompilerThread0
+ 5347 thread_start (in libsystem_pthread.dylib) + 13 [0x7fff930c3351]
+ 5347 _pthread_start (in libsystem_pthread.dylib) + 168 [0x7fff930c591a]
+ 5347 _pthread_body (in libsystem_pthread.dylib) + 131 [0x7fff930c599d]
+ 5347 java_start(Thread*) (in libjvm.dylib) + 246 [0x112485bbe]
+ 5347 JavaThread::run() (in libjvm.dylib) + 450 [0x112566344]
+ 5347 JavaThread::thread_main_inner() (in libjvm.dylib) + 155 [0x112564c57]
+ 5347 CompileBroker::compiler_thread_loop() (in libjvm.dylib) + 376 [0x1121b89ce]
+ 5347 CompileQueue::get() (in libjvm.dylib) + 122 [0x1121b87ac]
+ 5347 Monitor::wait(bool, long, bool) (in libjvm.dylib) + 222 [0x11245f5a0]
+ 5347 Monitor::IWait(Thread*, long) (in libjvm.dylib) + 168 [0x11245f3d0]
+ 5347 os::PlatformEvent::park(long) (in libjvm.dylib) + 404 [0x112482844]
+ 5347 _pthread_cond_wait (in libsystem_pthread.dylib) + 767 [0x7fff930c6728]
+ 5347 __psynch_cvwait (in libsystem_kernel.dylib) + 10 [0x7fff8dbbcdb6]
此外，其余线程具有这些堆栈跟踪（每个线程一行）
_OSSpinLockLockSlow ! syscall_thread_switch _OSSpinLockLockSlow _pthread_lookup_thread pthread_kill os::SuspendedThreadTask::internal_do_task() os::SuspendedThreadTask::run() ThreadSampleClosure::sample_thread(JavaThread*, 5347 Thread_669693
__accept BsdAttachListener::dequeue() AttachListener::dequeue() attach_listener_thread_entry(JavaThread*, JavaThread::thread_main_inner() JavaThread::run() java_start(Thread*) _pthread_body 5347 Thread_669711: Java: Attach Listener
__psynch_cvwait _pthread_cond_wait Parker::park(bool, Unsafe_Park ??? ??? 5347 Thread_669715: Java: RMI Scheduler(0)
__psynch_cvwait _pthread_cond_wait Parker::park(bool, Unsafe_Park ??? ??? ??? ??? 5347 Thread_669777: Java: log4j2.jmx.notif1
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ObjectMonitor::wait(long, ObjectSynchronizer::wait(Handle, JVM_MonitorWait ??? ??? 5347 Thread_669603
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ObjectMonitor::wait(long, ObjectSynchronizer::wait(Handle, JVM_MonitorWait ??? ??? 5347 Thread_669657: Java: Reference Handler
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ObjectMonitor::wait(long, ObjectSynchronizer::wait(Handle, JVM_MonitorWait ??? ??? 5347 Thread_669658: Java: Finalizer
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ParkCommon(ParkEvent*, Monitor::ILock(Thread*) Monitor::lock(Thread*) G1CollectedHeap::attempt_allocation_slow(unsigned G1CollectedHeap::attempt_allocation(unsigned 5347 Thread_669669: Java: JFR request timer
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ParkCommon(ParkEvent*, Monitor::ILock(Thread*) Monitor::lock(Thread*) G1CollectedHeap::attempt_allocation_slow(unsigned G1CollectedHeap::attempt_allocation(unsigned 5347 Thread_669712: Java: RMI TCP Accept-0
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ParkCommon(ParkEvent*, Monitor::ILock(Thread*) Monitor::lock(Thread*) G1CollectedHeap::attempt_allocation_slow(unsigned G1CollectedHeap::attempt_allocation(unsigned 5347 Thread_669720: Java: JMX server connection timeout 29
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ParkCommon(ParkEvent*, Monitor::ILock(Thread*) Monitor::lock(Thread*) G1CollectedHeap::attempt_allocation_slow(unsigned G1CollectedHeap::attempt_allocation(unsigned 5347 Thread_683755: Java: RMI TCP Connection(65)-192.168.1.167
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ParkCommon(ParkEvent*, Monitor::ILock(Thread*) Monitor::lock(Thread*) G1CollectedHeap::attempt_allocation_slow(unsigned G1CollectedHeap::attempt_allocation(unsigned 5347 Thread_813902: Java: RMI TCP Connection(634)-192.168.1.167
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ParkCommon(ParkEvent*, Monitor::ILock(Thread*) Monitor::lock(Thread*) SafepointSynchronize::begin() VMThread::loop() 5347 Thread_669656
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ParkCommon(ParkEvent*, Monitor::ILock(Thread*) Monitor::lock_without_safepoint_check() SafepointSynchronize::block(JavaThread*) ThreadStateTransition::trans_and_fence(JavaThreadState, 5347 Thread_669676: Java: VM JFR Buffer Thread
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ParkCommon(ParkEvent*, Monitor::IWait(Thread*, Monitor::wait(bool, ConcurrentMarkThread::sleepBeforeNextCycle() ConcurrentMarkThread::run() 5347 Thread_669645
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ParkCommon(ParkEvent*, Monitor::IWait(Thread*, Monitor::wait(bool, ServiceThread::service_thread_entry(JavaThread*, JavaThread::thread_main_inner() 5347 Thread_669692: Java: Service Thread
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ParkCommon(ParkEvent*, Monitor::IWait(Thread*, Monitor::wait(bool, SurrogateLockerThread::loop() JavaThread::thread_main_inner() 5347 Thread_669667: Java: Surrogate Locker Thread (Concurrent GC)
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ParkCommon(ParkEvent*, Monitor::IWait(Thread*, Monitor::wait(bool, SuspendibleThreadSet::join() ConcurrentG1RefineThread::sample_young_list_rs_lengths() 5347 Thread_669626
__semwait_signal pthread_join ContinueInNewThread0 ContinueInNewThread JVMInit JLI_Launch main apple_main 5347 Thread_669600
__sigsuspend SR_handler(int, _sigtramp vframeStreamCommon::fill_from_frame() _pthread_lookup_thread pthread_kill closefd ??? 5347 Thread_671069: Java: DelayClose
kevent_qos _dispatch_mgr_invoke _dispatch_mgr_thread 5347 Thread_669601 DispatchQueue_2: com.apple.libdispatch-manager (serial)
mach_msg_trap mach_msg __CFRunLoopServiceMachPort __CFRunLoopRun CFRunLoopRunSpecific CreateExecutionEnvironment JLI_Launch main 5347 Thread_669599 DispatchQueue_1: com.apple.main-thread (serial)
semaphore_wait_trap check_pending_signals(bool) signal_thread_entry(JavaThread*, JavaThread::thread_main_inner() JavaThread::run() java_start(Thread*) _pthread_body _pthread_start 5347 Thread_669668: Java: Signal Dispatcher
__psynch_cvwait _pthread_cond_wait os::PlatformEvent::park() ParkCommon(ParkEvent*, Monitor::ILock(Thread*) Monitor::lock(Thread*) G1CollectedHeap::attempt_allocation_slow(unsigned 5347 Thread_815183: Java: RMI TCP Connection(635)-192.168.1.167
我省略了我的 300 个线程，因为 Java 不在安全点（jstack 不起作用），所以饥饿不能是因为我的（用户）线程。饥饿肯定是由 VM 线程引起的（我在上面列出的所有这些都带有堆栈跟踪）。
2016 年 6 月 24 日更新：
我做了jstack -F，我的线程被阻塞了，一些内存操作，比如这个
Thread 200451: (state = BLOCKED)
- java.util.Arrays.copyOf(char[], int) @bci=1, line=3332 (Compiled frame)
- java.lang.AbstractStringBuilder.expandCapacity(int) @bci=43, line=137 (Compiled frame)
- java.lang.AbstractStringBuilder.ensureCapacityInternal(int) @bci=12, line=121 (Compiled frame)
- java.lang.AbstractStringBuilder.append(java.lang.String) @bci=21, line=421 (Compiled frame)
- java.lang.StringBuilder.append(java.lang.String) @bci=2, line=136 (Compiled frame)
但 jstack 不显示垃圾收集器线程。为此，我在同一个进程上运行示例命令，就像在您看到饥饿的 GC 线程之前一样：
+ 5229 ??? (in <unknown binary>) [0x11064ae07]
+ 5229 OptoRuntime::new_array_nozero_C(Klass*, int, JavaThread*) (in libjvm.dylib) + 54 [0x10f8da854]
+ 5229 TypeArrayKlass::allocate_common(int, bool, Thread*) (in libjvm.dylib) + 138 [0x10f975406]
+ 5229 CollectedHeap::common_mem_allocate_noinit(KlassHandle, unsigned long, Thread*) (in libjvm.dylib) + 105 [0x10f4b2bbb]
+ 5229 CollectedHeap::allocate_from_tlab_slow(KlassHandle, Thread*, unsigned long) (in libjvm.dylib) + 283 [0x10f59e2af]
+ 5229 G1CollectedHeap::allocate_new_tlab(unsigned long) (in libjvm.dylib) + 28 [0x10f65590e]
+ 5229 G1CollectedHeap::attempt_allocation(unsigned long, unsigned int*, unsigned int*) (in libjvm.dylib) + 182 [0x10f65e42a]
+ 5229 G1CollectedHeap::attempt_allocation_slow(unsigned long, unsigned char, unsigned int*, unsigned int*) (in libjvm.dylib) + 339 [0x10f6576ab]
+ 5229 Monitor::lock(Thread*) (in libjvm.dylib) + 132 [0x10f85f2c6]
+ 5229 Monitor::ILock(Thread*) (in libjvm.dylib) + 310 [0x10f85f1bc]
+ 5229 ParkCommon(ParkEvent*, long) (in libjvm.dylib) + 42 [0x10f85eafa]
+ 5229 os::PlatformEvent::park() (in libjvm.dylib) + 192 [0x10f88195a]
+ 5229 _pthread_cond_wait (in libsystem_pthread.dylib) + 767 [0x7fff930c6728]
+ 5229 __psynch_cvwait (in libsystem_kernel.dylib) + 10 [0x7fff8dbbcdb6]
当我只用 30 个线程（而不是 300 个）运行我的应用程序时，饥饿就消失了。
我们需要找出垃圾收集器的__psynch_cvwait在哪个锁上等待，但是jstack没有说这个。可能代码检查是最好的选择。