Java 什么是 weblogic.socket.Muxer？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1623692/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is weblogic.socket.Muxer?
提问by Andrey Adamovich
Does any of you understand what weblogic.socket.Muxer is used for in WebLogic 8.1?
你们中有人了解 weblogic.socket.Muxer 在 WebLogic 8.1 中的用途吗？
Often in thread dumps I see stack traces similar to this:
我经常在线程转储中看到类似这样的堆栈跟踪：
"ExecuteThread: '0' for queue: 'weblogic.socket.Muxer'" id=20 idx=0x68 tid=26709 prio=5 alive, in native, blocked, daemon
-- Blocked trying to get lock: java/lang/String@0x2b673d373c50[fat lock]
at jrockit/vm/Threads.waitForUnblockSignal()V(Native Method)
at jrockit/vm/Locks.fatLockBlockOrSpin(Locks.java:1675)[optimized]
at jrockit/vm/Locks.lockFat(Locks.java:1776)[optimized]
at jrockit/vm/Locks.monitorEnterSecondStageHard(Locks.java:1312)[optimized]
at jrockit/vm/Locks.monitorEnterSecondStage(Locks.java:1259)[optimized]
at jrockit/vm/Locks.monitorEnter(Locks.java:2439)[optimized]
at weblogic/socket/EPollSocketMuxer.processSockets(EPollSocketMuxer.java:153)
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)
at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
-- end of trace
It's not that I have any problems with that, it is just intresting to understand:
并不是说我对此有任何问题，只是理解起来很有趣：
1) what is it doing?
2) can it affect any performance?
1）它在做什么？
2）它会影响任何性能吗？
采纳答案by Pascal Thivent
From the documentation (http://download.oracle.com/docs/cd/E13222_01/wls/docs100/perform/WLSTuning.html#wp1152246):
从文档（http://download.oracle.com/docs/cd/E13222_01/wls/docs100/perform/WLSTuning.html#wp1152246）：
WebLogic Server uses software modules called muxers to read incoming requests on the server and incoming responses on the client. These muxers are of two primary types: the Java muxer or native muxer.
A Java muxer has the following characteristics:
- Uses pure Java to read data from sockets.
- It is also the only muxer available for RMI clients.
- Blocks on reads until there is data to be read from a socket. This behavior does not scale well when there are a large number of sockets and/or when data arrives infrequently at sockets. This is typically not an issue for clients, but it can create a huge bottleneck for a server.
Native muxers use platform-specific native binaries to read data from sockets. The majority of all platforms provide some mechanism to poll a socket for data. For example, Unix systems use the poll system and the Windows architecture uses completion ports. Native provide superior scalability because they implement a non-blocking thread model. When a native muxer is used, the server creates a fixed number of threads dedicated to reading incoming requests. BEA recommends using the default setting of selected for the
Enable Native IOparameter which allows the server automatically selects the appropriate muxer for the server to use.If the
Enable Native IOparameter is not selected, the server instance exclusively uses the Java muxer. This maybe acceptable if there are a small number of clients and the rate at which requests arrive at the server is fairly high. Under these conditions, the Java muxer performs as well as a native muxer and eliminate Java Native Interface (JNI) overhead. Unlike native muxers, the number of threads used to read requests is not fixed and is tunable for Java muxers by configuring thePercent Socket Readersparameter setting in the Administration Console. See Changing the Number of Available Socket Readers. Ideally, you should configure this parameter so the number of threads roughly equals the number of remote concurrently connected clients up to 50% of the total thread pool size. Each thread waits for a fixed amount of time for data to become available at a socket. If no data arrives, the thread moves to the next socket.
WebLogic Server 使用称为多路复用器的软件模块来读取服务器上的传入请求和客户端上的传入响应。这些多路复用器有两种主要类型：Java 多路复用器或本机多路复用器。
Java 多路复用器具有以下特征：
- 使用纯 Java 从套接字读取数据。
- 它也是唯一可用于 RMI 客户端的多路复用器。
- 阻塞读取，直到有数据要从套接字读取。当有大量套接字和/或数据很少到达套接字时，这种行为不能很好地扩展。这对于客户端来说通常不是问题，但它会给服务器造成巨大的瓶颈。
本机复用器使用特定于平台的本机二进制文件从套接字读取数据。大多数平台都提供了某种机制来轮询套接字以获取数据。例如，Unix 系统使用轮询系统，Windows 体系结构使用完成端口。Native 提供了卓越的可扩展性，因为它们实现了非阻塞线程模型。使用本机复用器时，服务器会创建固定数量的线程，专用于读取传入请求。BEA 建议对
Enable Native IO参数使用默认设置 selected， 它允许服务器自动选择合适的多路复用器供服务器使用。如果
Enable Native IO未选择该参数，则服务器实例将专门使用 Java 多路复用器。如果客户端数量很少并且请求到达服务器的速率相当高，这可能是可以接受的。在这些条件下，Java 多路复用器的性能与本机多路复用器一样好，并消除了 Java 本机接口 (JNI) 开销。与本机多路复用器不同，用于读取请求的线程数不是固定的，可以通过Percent Socket Readers在管理控制台中配置参数设置为 Java 多路复用器进行调整。请参阅更改可用套接字读取器的数量. 理想情况下，您应该配置此参数，使线程数大致等于远程并发连接的客户端数，最多为总线程池大小的 50%。每个线程等待固定的时间，以便数据在套接字上可用。如果没有数据到达，线程将移动到下一个套接字。
Then, for those reasons, it is obviously better to use native muxers.
那么，由于这些原因，使用原生多路复用器显然更好。
Here, it looks like you are using the default native muxer (weblogic.socket.EPollSocketMuxer), not the Java muxer (weblogic.socket.SocketMuxer).
在这里，您似乎使用的是默认的本机多路复用器 ( weblogic.socket.EPollSocketMuxer)，而不是 Java 多路复用器 ( weblogic.socket.SocketMuxer).
回答by skaffman
For any given application server, a thread dump will show you hundreds, if not thousands, of background threads. These servers are complex beasts, and these threads are just the background plumbing doing its job.
对于任何给定的应用程序服务器，线程转储将显示数百甚至数千个后台线程。这些服务器是复杂的野兽，而这些线程只是完成其工作的后台管道。
A "muxer" is a multiplexer, which is a mechanism for combining several streams of data on to a single channel. Weblogic will be using these to exchange data with itself, or with other nodes in the cluster. At any given time, a number of those will be "blocked", since they have nothing to do.
“多路复用器”是一种多路复用器，它是一种将多个数据流组合到单个通道上的机制。Weblogic 将使用这些与自身或集群中的其他节点交换数据。在任何给定时间，其中一些将被“阻止”，因为它们无所事事。
It's almost certainly no cause for concern. If you look under the rock, you're bound to find a few ugly things underneath blinking up at you in the sunlight.
几乎可以肯定，这无需担心。如果你往岩石下面看，你一定会发现下面有一些丑陋的东西在阳光下向你眨眼。
回答by Andrey Adamovich
I have found this linkthat explained the situation pretty much:
我发现这个链接可以很好地解释这种情况：
The socket Muxer manages the server's existing socket connections. It first determines which sockets have incoming requests waiting to be processed. It then reads enough data to determine the protocol and dispatches the socket to an appropriate runtime layer based on the protocol. In the runtime layer, the socket muxer threads determine which execute thread queue to be used and delegates the request accordingly.
套接字复用器管理服务器现有的套接字连接。它首先确定哪些套接字有等待处理的传入请求。然后它读取足够的数据来确定协议并根据协议将套接字分派到适当的运行时层。在运行时层，套接字复用器线程确定要使用的执行线程队列并相应地委托请求。
