背景
今天记录一个小问题。
问题不大，也没什么分析的逻辑可以讲的。但是想着比较典型，所以就写一写。
这一日，一个朋友发来个问题。
?
一个 Java 应用,从 visualVm 这里看，有 10 个 new I/O worker 线程。具体 top -d -Ph pid 看到只有一个线程在忙。
问题分析
听起来是个问题。一个线程忙，这种情况应该比较好处理吧。
再看一下 CPU 的状态是什么样， 记住这一步是看进程中的线程。这种操作我想看过 7DGroup 公众号上文章的人都已经会了。
然后印下 dump信 息。printf 转换下 pid 到十六进制，查到如下进程：
"New I/O worker #8" #124 daemon prio=5 os_prio=0 tid=0x00007f4c100a2800 nid=0xd232 runnable [0x00007f4ba45c7000]
java.lang.Thread.State: RUNNABLE
at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:2449)
at com.alibaba.dubbo.common.serialize.support.hessian.Hessian2ObjectInput.readObject(Hessian2ObjectInput.java:76)
at com.alibaba.dubbo.rpc.protocol.dubbo.DecodeableRpcResult.decode(DecodeableRpcResult.java:83)
at com.alibaba.dubbo.rpc.protocol.dubbo.DecodeableRpcResult.decode(DecodeableRpcResult.java:109)
at com.alibaba.dubbo.rpc.protocol.dubbo.DubboCodec.decodeBody(DubboCodec.java:90)
at com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:118)
at com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:79)
at com.alibaba.dubbo.rpc.protocol.dubbo.DubboCountCodec.decode(DubboCountCodec.java:46)
at com.alibaba.dubbo.remoting.transport.netty.NettyCodecAdapter$InternalDecoder.messageReceived(NettyCodecAdapter.java:134)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
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)
Locked ownable synchronizers:
- <0x00000007500fccf0> (a java.util.concurrent.ThreadPoolExecutor$Worker)
这其实是一个挺明确的问题，如果理解了dubbo 的话。
不止是 dubbo，对其他的应用也是同样的判断逻辑。如果只有一个 CPU 使用率高。
?
那就三个方向：
- 单线程；
- 锁或等待；
- 等待。
可是现在是什么年代了？还能有单线程的问题吗？嗯，确实是有的，不管年代。
对于 dubbo 这种配置参数如此之繁杂的玩意来说，配置更需要麻烦。之前我整理过 dubbo 和性能相关的参数，有比较直接的关联关系的大概就有四十几个（包括消耗者和生产者）。
在我们的性能分析中，其实有一个环节，至今我看到仍然做的非常差的，就是事先把性能配置参数给梳理一遍。有些问题在梳理的时候就可以看出来了，所以我在工作的时候，在做性能分析之前，都会先干一遍这样的事情。
比如说 Linux 的参数（下图中红色为性能参数，做了标识）：
上图只是展示了一部分，全部参数是什么样的呢？
样算一屏的话，大概有三屏的参数。
可以想像，配置那么多，在出现性能问题时怎么分辨？
并且一个参数问题，导致的问题表象都会让你觉得非常不理解。
有时候我们费了几天的劲分析了一个问题，最后发现是一个参数导致的，改一下就性能大涨，会觉得特别不值得，想骂人的感觉有没有?
有的人看着写文章中一个性能问题，觉得到最后改一个IP、改一个参数、改一行代码、改一个SQL，就会觉得性能问题无非就是这样嘛。
但是你想过没有，这个过程中要分析多少数据？做多少实验？要多有耐心？要多需要功底？
感慨的差不多了，说一下上面的问题是什么原因吧，要不然，看官们该想扔手机了！
上面的问题是什么呢就是一个 connections 配置。这个朋友是把 connections 放到代码里的，写成了这样。
referenceConfig.setConnections(1);
因为限制了连接为 1，并且在压测的这个环境中，一个 consumer 一个 provider。这样一来，就完全限制住了吞吐量。
其实是实际的生产 dubbo 环境中，并不完全是这样。当 consumer 和 provider 多的时候，CPU 也可以用得起来。
但是在这个特定的环境中，就完全被限制了。怎么办呢？这时候，就简单了对不对。
referenceConfig.setConnections(10);
这样就可以用起来了。
小结
因为这个问题比较简单，记录下来，就是为了告诉玩性能的人们，你要关心性能配置参数。
应该说，什么都得关心，缺少一个环节，就是知识的盲区。