标签:channel count href views div getc 间隔 微博 one
之前更新了几篇关于JVM研究的文章,其实也是在做本篇文章验证的时候,跑的有点远,呵呵。回归Netty教程,这次要讲的其实是针对一个问题的研究和验证结论。另外,最近工作比较忙,所以可能会分文章更新一些阶段性的成果,而不是全部汇总更新,以免间隔过久。
起因是一个朋友,通过微博(OneCoder腾讯微博、OneCoder新浪微博、OneCoder网易微博、OneCoder搜狐微博)私信给我一个问题,大意是说他在用Netty做并发测试的时候,会出现大量的connection refuse信息,问我如何解决。
没动手就没有发言权,所以OneCoder决定测试一下:
01.
/**
02.
* @author lihzh
03.
* @alia OneCoder
04.
* @blog http://www.coderli.com
05.
*/
06.
public
class
ConcurrencyNettyTestHandler
extends
SimpleChannelHandler {
07.
08.
private
static
int
count =
0
;
09.
10.
/**
11.
* 当接受到消息的时候触发 www.it165.net
12.
*/
13.
@Override
14.
public
void
channelConnected(ChannelHandlerContext ctx,
15.
final
ChannelStateEvent e)
throws
Exception {
16.
for
(
int
i =
0
; i <
100000
; i++) {
17.
Thread t =
new
Thread(
new
Runnable() {
18.
@Override
19.
public
void
run() {
20.
sendObject(e.getChannel());
21.
}
22.
});
23.
System.out.println(
"Thread count: "
+ i);
24.
t.start();
25.
}
26.
27.
}
28.
29.
/**
30.
* 发送Object
31.
*
32.
* @author lihzh
33.
* @alia OneCoder
34.
*/
35.
private
void
sendObject(Channel channel) {
36.
count++;
37.
Command command =
new
Command();
38.
command.setActionName(
"Hello action."
);
39.
System.out.println(
"Write: "
+ count);
40.
channel.write(command);
41.
}
42.
}
运行结果:
Hello action.: 99996
Hello action.: 99997
Hello action.: 99998
Hello action.: 99999
Hello action.: 100000
你可能会惊讶,10w个请求都能通过?呵呵,细心的同学,可能会发现,这其实并不是并发,而只是所谓10w个线程的,单channel的伪并发,或者说是一种持续的连续访问。并且,如果你跑一下测试用例,会发现,Server端开始接受处理消息,是在Client端10w个线程请求都结束之后再开始的。这是为什么?
其实,如果您看过OneCoder的《Java NIO框架Netty教程(七)-再谈收发信息次数问题http://www.it165.net/pro/html/201207/3287.html》,应该会有所联想。不过坦白的说,OneCoder也是在经过一番周折,一番Debug以后,才发现了这个问题。当OneCoder在线程内断点以后,放过一个线程,接收端就会有一条信息出现,这其实是和之前文章里介绍的场景是一样的。所以,呵呵,可能对您来说,看了这篇文章,并没有更多的收获,但是对OneCoder来说,确实是经历了不小的周折,绕了挺大的弯子,也算是对代码的再熟悉过程吧。
下篇我们会面对真正并发的问题:)
Java NIO框架Netty教程(十一) 并发访问测试(上)
标签:channel count href views div getc 间隔 微博 one
原文地址:http://www.cnblogs.com/hashcoder/p/7648419.html