纯Java的高性能长连接RPC解决方案

不知道楼主还有空回复不。
我用楼主的的代码，用来做聊天室，压力测试用的客户端C语言现写的，1W5的线程，1W5的tcp连接，每秒大约1-2个人说话，一直说，每次说话都是accept 1 ,  write 给1W5个channel的广播模式。
最开始好多问题，比如每次write动作都要dynamic一个buffer，各种GC模式都很难回收，我同样为每个channel保持了一个buffer做了个k/V缓存来重用，buffer和byte[]问题解决了，现在的问题就是，New IO Worker 下面的LinkedTransferQueue -> Node(DownStreamMessageEvent)，每个Event对象里面还有Future对象，这一连串的内外对象，始终不回收。发了200W次就有200W个对象，Jmap+MAT分析 几个对象数量基本相等，FULLGC也回收不掉。现在内存瓶颈只有这个了，一段时间后OOM，程序僵死，无限FULLGC，CPU无压力。有点焦头烂额了。。。哈哈。我不知道楼主的单机50W是1进1出，一读一写的模式吗。没有广播的模式吧。能帮忙分析一下吗。
是交换队列处理不过来吗？处理完为什么NODE不被释放。NODE释放对应的event,future不就都释放了吗。就全OK，长久压力条件下运行了。

你广播发出消息后，接收方不对消息作出应答吗？

客户端自己乱用C语言搞的，只sent给我的netty, 并没有使用recieve，难道是以为这个，导致这些对象的几百万实例全部存活吗？

楼主，你封装的netty如何在 IOS下调用啊，有没有例子代码啊，我想在IOS下用长连接

我不是楼主，但是大同小异，这个只是服务端，处理的也只是标准socket 的byte[]协议，4+1+N的数据包，客户端是什么无所谓，只要是socket tcp长连接就可以，我的客户端就是C语言的，不过IOS的objc我就不会了 哈哈

你客户端不处理recieve，服务器端不关心，服务器端对象常驻，是由于客户端的连接没有断开，且频繁的处于活跃状态，所以服务器端的socket对象不会关闭，一直停留在内存。

我虽然不会写ios，但是你按照作者的数据包格式发送一个socket数据包，然后再接收一下服务器端的返回的数据包，应该就可以了。只不过你要自己实现作者实现的心跳包，如果不想用心跳包功能，也可以不做，这个对于业务来说不是必须的。

争论个毛，想看的就看看，不想看的就别看，眼睛里除了质疑还有什么

牛的自己搞个去，看看人家优点，竟抓着人家不好的地方，你也弄点你认为像样的出来给大家看看

中国的开源环境就被这帮人搞坏了，自己搞不出什么东西，别人给你用了还喋喋不休这不好那不好的




最后支持楼主

大家在从技术层面进行探讨，可以说在使用中遇到问题，然后分享出来，这可能是使用者的问题，也可能是作者代码中潜在的bug。总之大家需要交流，众人拾柴火焰高，这才是开源的目的与精神。我想作者也不是个见到有人提出疑问，就火冒三丈的人，作者吧代码分享出来，肯定是了接收大家的检阅。如果别人提了意见后置若罔闻，或者干脆不允许别人提意见，那其实跟闭源没啥区别了。

完成正确，我也是这个意思，不过最近真的不好意思公司脱产培训了两周才回来， 后会尽量回答各位的问题