如何分析WebLogic线程转储？
我注意到有一些卡住的线程。
我喜欢根据下面的线程转储日志来检查线程卡住的原因是什么。有什么建议吗？还有粗锁和细锁有什么区别？
"[STUCK] ExecuteThread: '25' for queue: 'weblogic.kernel.Default (self-tuning)'" id=87495 idx=0x274 tid=15308 prio=1 alive, in native, blocked, daemon
-- Blocked trying to get lock: com/jnn/testController@0x135a26c0[thin lock]
I notice that there are some stuck threads.
I like to check what could be the cause of the stuck thread just base on the thread dump logs below. Any advise anyone? And also what is the difference between a fat lock and a thin lock?
"[STUCK] ExecuteThread: '25' for queue: 'weblogic.kernel.Default (self-tuning)'" id=87495 idx=0x274 tid=15308 prio=1 alive, in native, blocked, daemon
-- Blocked trying to get lock: com/jnn/testController@0x135a26c0[thin lock]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
仅使用一组线程转储对于找出根本原因并没有多大帮助。进行 4 或 5 组线程转储，每组之间的间隔为 5 秒。因此，最后您将得到一个日志文件，其中包含应用程序服务器上大约 20 - 25 秒的操作。
然后你应该寻找你想要检查的是卡住的线程还是长时间运行的事务正在发生，所有线程转储将显示某个线程 ID 位于 java 堆栈跟踪的同一行。简单来说，事务（例如在 EJB 或数据库中）跨越多个线程转储，因此需要更多调查。
现在，当您通过 Samurai 或 TDA 运行这些时（我自己没有使用过 TDA），它将以红色突出显示这些内容，以便您可以快速单击它并转到显示问题的行。
请参阅此处的示例。查看该链接中的 Samurai 输出图像。绿色就好。红色和灰色需要注意。
在您的情况下，线程 25 在尝试获取该对象上的锁时被阻止
搜索锁的其余部分以查看什么在同一对象上持有锁，并查看为什么它不释放锁 - 这将在堆栈跟踪
One set of thread dumps alone wont be too helpful to get to the root cause. Take 4 or 5 sets of thread dumps at an interval of 5 seconds between each. so at the end you will have a single log file which has around 20 - 25 seconds worth of action on the app server.
Then you should look for you want to check is a stuck thread or long running transaction is happening, all the thread dumps will show a certain thread id is at the same line in your java stack trace. In simpler terms, the transaction (say in an EJB or database) is spanning across multiple thread dumps and hence needs more investigation.
Now when you run these through Samurai or TDA (I havent used TDA myself), it will highlight these in Red colour so you can quickly click on it and get to the lines showing issues.
See an example of this here. Look at the Samurai output image in that link. Green is fine. Red and grey need looking at.
In your case, thread 25 is blocked trying to get the lock on this object
Search the rest of the lock to see what is holding a lock on the same object, and see why it is not releasing the lock - this will be visible in the stack trace
“瘦锁”是没有争用的锁（当线程在获取锁之前必须等待时，就会发生争用）。
当存在争用并且所有等待获取锁的线程都创建一个列表时，瘦锁会升级为“胖锁”。
您可以在此处阅读有关该论点的更多信息：
http://download.oracle.com/docs /cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/thread_basics.html
A "thin lock" is a lock with no contention (contention happens when a thread has to wait before acquiring a lock).
Thin locks get promoted to "Fat locks" when there is contention and a list is made with all threads waiting to acquire the lock.
You can read more on the argument here:
http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/thread_basics.html