Netty的UDP多線程源碼改造分析

參考：

http://m.oschina.net/blog/527583?from=timeline&isappinstalled=1

https://lwn.net/Articles/542629/

http://www.tuicool.com/articles/Rry6biF

http://www.blogjava.net/yongboy/archive/2015/02/25/423037.html  ！！！

 

默認狀況下，用Netty-4.0.33 ,啓動的線程只有1個。

可是現網的流量確實比較大怎麼辦？

就須要去改造源碼。

==========

通過分析，註冊udp channel的線程棧以下所示：

通過源碼排查，

at io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:48)
 at io.netty.channel.MultithreadEventLoopGroup.register(MultithreadEventLoopGroup.java:64)

問題在這裏，若是去看源碼就知道

找到緣由，就好辦了，前進的方向也就有了！

=================================

修改方案：

1 添加一個參數

io.netty.channel.ChannelOption添加以下： 

public static final ChannelOption<Boolean> SO_REUSEPORT = valueOf("SO_REUSEPORT");

 

2使用起來這個參數

啓動框架裏添加這麼一行

.option(ChannelOption.SO_REUSEPORT, true) 

同時也添加

.option(ChannelOption.SO_REUSEADDR, true)

 

 

 

3 觸發屢次綁定操做

主函數修改後的代碼以下： 

public void start() {

int totalThreads = SystemPropertyUtil.getInt("io.netty.eventLoopThreads",

Runtime.getRuntime().availableProcessors() * 2);

EventLoopGroup group = new NioEventLoopGroup(totalThreads);

try {

Bootstrap b = new Bootstrap();

b.group(group).channel(NioDatagramChannel.class)

.option(ChannelOption.SO_BROADCAST, true)

.option(ChannelOption.SO_REUSEADDR, true)

.option(ChannelOption.SO_REUSEPORT, true)

.handler(new UDPServerHandler());

 

ChannelFuture futures[] = new ChannelFuture[totalThreads];

for (int i = 0; i < totalThreads; i++) {// 爲了啓動相應的線程

futures[i] = b.bind(port).sync();

}

for (int i = 0; i < totalThreads; i++) {// 爲了等待相應的線程關閉

futures[i].channel().closeFuture().await();

}

 

} catch (InterruptedException e) {

logger.error("", e);

} finally {

group.shutdownGracefully();

}

}

 

4 異常處理

此時報異常：

這個異常卻是很奇怪。

這個問題怎麼解決呢。。。

 

把主函數的代碼修改下

.handler(new UDPServerHandler());這個是必需要保留的，不然會報錯。

 

而後在類io.netty.bootstrap.Bootstrap.init(Bootstrap.java:182)

這裏的代碼從p.addLast(handler());修改爲

p.addLast(new UDPServerHandler());

 

再來測試看看：成功啓動了。

至少線程啓動了。

 

客戶端發點數據看看結果：

發現始終是同一個線程處理，這個問題就比較麻煩，咱們的客戶機是同一個主機。

 

這個問題怎麼解決呢？

看到一個文章： http://blog.csdn.net/dog250/article/details/17061277

至少能夠在發送端設置不一樣的端口解決這個問題，性能能夠提高，有興趣的本身試驗下。