I have a thread dump and Memory dump of my process where a thread is hung
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000000070feebf40> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at voldemort.store.readonly.chunk.DataFileChunkSetIterator.<init>(DataFileChunkSetIterator.java:66)
at voldemort.store.readonly.chunk.ChunkedFileSet$ROKeyIterator.<init>(ChunkedFileSet.java:617)
at voldemort.store.readonly.ReadOnlyStorageEngine.keys(ReadOnlyStorageEngine.java:478)
at voldemort.server.protocol.admin.FullScanFetchStreamRequestHandler.<init>(FullScanFetchStreamRequestHandler.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
But I need to see what object is at the memory location 0x000000070feebf40 . Is there an easy way to see this object ? Both YourKit and jvisualvm does not see what is in at this memory address.
I tried looking by instances but there are 300 of them for most of them which makes it really difficult to analyze.
I have used C# and there you can easily search the memory using WinDbg and sos plugin.
如果您有堆转储和要查找的对象的位置,请在VisualVM中加载该转储并在OQL控制台中使用以下查询
select heap.findObject("0x00000000fe9d4910")
I do not think that 0x000000070feebf40 is an address in memory. This is object identity hash code. Identity hash-code is persistent, but address in memory is volatile (GC moves objects).
And what exactly would you get after figuring out the object in memory? That's an internal object of ReentrantReadWriteLock
at which the thread had parked waiting for acquire
to succeed (which means the lock is busy). To diagnose just about any real issue, it is way better to look into the source. This part of the stack:
...
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at voldemort.store.readonly.chunk.DataFileChunkSetIterator.<init>(DataFileChunkSetIterator.java:66)
...
...means you are looking for a ReentrantReadWriteLock.readLock().lock()
in DataFileChunkSetIterator
constructor.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.