Question

这在我的应用程序中确实是一个阻塞问题吗？

weblogic.socket.DevPollSocketMuxer.processSockets(DevPollSocketMuxer.java:92)在线程分析器中显示阻塞，它是否真的是一个我应该担心的阻塞线程？

ExecuteThread: '3' for queue: 'weblogic.socket.Muxer'"   daemon prio=3 tid=0x0000000101f38000 nid=0x38 waiting for monitor entry [0xfffffffe40dff000]      
java.lang.Thread.State: BLOCKED (on object monitor)      at 
weblogic.socket.DevPollSocketMuxer.processSockets(DevPollSocketMuxer.java:92)      - 
waiting to lock <0xfffffffe70ec4898> (a java.lang.String)      at 
weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)      at 
weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:42)      at 
weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:145)      at 
weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)

编辑：

我得到了link解释答案（其中说这不是问题）但不确定被阻止的线程可以用于什么目的？为什么这样设计？所以改变问题的标题如下

旧标题 - weblogic.socket.DevPollSocketMuxer.processSockets在线程分析器中显示阻塞，它是否真的是一个我应该担心的阻塞线程？

新标题 - 为什么阻止weblogic.socket.Muxer线程可以接受？它的目的是什么？

Answer 1

观察要阻塞的Muxer线程不是问题，这是正常行为。你不应该担心这个。

muxer线程争用轮询锁来对文件描述符进行轮询，因此大量线程不会增加任何好处。一个Muxer线程通常在poll函数中，而其他线程可用于处理请求。轮询线程在线程转储中可见。

以下是更多细节：

请参阅Analyzing Thread Dumps in Middleware - Part 2 - 一篇描述所有不同WSL线程转储情况的好文章 - 包括Muxer线程。他们说：

可以看到ExecuteThread：'5'和'4'都属于带有ExecuteThread的weblogic.socket.Muxer队列：'5'持有对java / lang / String @ 0x17674d0c8和ExecuteThread：'4'的锁定阻止同一个锁。持有锁的Muxer线程正在进行本机轮询，而其他muxer线程被阻塞，因为只有一个线程在一组fds上进行轮询。

其他资源：

Muxer线程调整：

即使线程在线程转储中保持BLOCKED并且您不必担心这一点，您仍需要检查是否为WLS实例分配了适当数量的线程 - 基于每个WLS实例的可用内核数量。请参阅Weblogic Tuning - Tuning Muxers。

为什么在weblogic中可以接受阻止weblogic.socket.Muxer线程？

1 个答案: