如何评价netty的buffer设计

乌龟壳 发布于 2017/05/17 22:14
阅读 1K+
收藏 2

开源之夏第三届火热来袭,高校学生参与赢万元奖金!>>>

@talent-tan

一直想请教一个问题,你曾经说过netty的buffer设计得其实不好。

我对这个的理解是jvm的实现无法针对高并发网络通信场景进行专门优化,所以netty设计了这个。但是想不出除了用起来确实反人类,还要人工给它做引用计数外,有什么别的缺陷吗?

另外补充一点,为什么我现在仍然首选netty,因为在我有空自己做一个网络框架之前,netty最符合我的需求的,各种网络通信协议都已经做了比较好的支持了。

加载中
0
talent-tan
talent-tan

我说一下

  1. 兄弟你参考我前面说的第3和第5条,我并非netty方面的专家,对netty的各种了解基本是通过网文知道的,我自己也是从netty未入门到放弃的典型
  2. 我没有说netty的bytebuffer设计得不好,但说过没有必要再封装一遍,原生的bytebuffer足够好用,netty所谓的零拷贝只是阶段性拷贝,对性能提升程度也有限,要是觉得我说的不可信,其实可以拿t-io对比测试一把(当然场景要一样,t-io内置了很多功能是给业务层用的,会影响一些测试性能)。
  3.  io密集型的,性能主要取决于多线程模型和解码编码算法,对象池在这种场景对性能提升极其有限----对象池是减少了GC,但是对象池的维护在对象创建密集型应用中消耗也很大,个人认为对象池一般用于那些对象创建很耗时的场景,比较典型的是数据库连接池这样的东西。
  4. 世界上只有极少数大神,但netty作者在我眼中不属于这个极少数,你如果能驾驭得了netty,其实完全可以没有后顾之忧地使用,毕竟netty的成功案例挺多!
  5. 我写t-io,并不表示我可以驾驭得了netty,当年也就是因为看不懂其api设计套路,才自己下定决心创建t-io的。
  6. 好吧,或许我说了一堆废话,另外t-io的源代码只有3000多行,如果兄弟有兴趣,可以看看t-io是怎么处理bytebuffer的,以你的功底,应该一天时间就能通看一遍。
talent-tan
talent-tan
回复 @kenneth123 : 没指望这个观点可以服众,仅仅是个人观点
k
kenneth123
你的观点不能服众,你的先了解netty才能评价
1
talent-tan
talent-tan
1、它的零拷贝只是阶段性拷贝,譬如我们在收发数据时最原始的对象其实是jdk的bytebuffer,netty做了个包装器,这个包装器是零拷贝的----其实就是加了一层指针。 2、jdk原生的bytebuffer足够好了,想不出为什么还要弄一套新的bytebuffer,最多写几个util方法即可 3、netty的源代码我没看,但是看过一些比较热的网文,而且我们也能根据jdk原始api推猜一些东西出来 4、你能驾驭netty,并且喜欢它的api,选择它没毛病啊,不需要听从别人的意见 5、我创造t-io是因为我某些智商不够用,掌握不好netty的api
0
乌龟壳
乌龟壳

引用来自“talent-tan”的评论

1、它的零拷贝只是阶段性拷贝,譬如我们在收发数据时最原始的对象其实是jdk的bytebuffer,netty做了个包装器,这个包装器是零拷贝的----其实就是加了一层指针。 2、jdk原生的bytebuffer足够好了,想不出为什么还要弄一套新的bytebuffer,最多写几个util方法即可 3、netty的源代码我没看,但是看过一些比较热的网文,而且我们也能根据jdk原始api推猜一些东西出来 4、你能驾驭netty,并且喜欢它的api,选择它没毛病啊,不需要听从别人的意见 5、我创造t-io是因为我某些智商不够用,掌握不好netty的api

netty的buffer有很多种。你说的加一层指针实现零拷贝的,这是协议解析中很常用的数据结构。

比如http头,第一层readline后,用这个结构包一下再给解析http头具体属性的代码,对于实现http头具体内容解析的代码来说,传来的就是一行数据。而实际只是在原来数据上加了层指针,而不是拷贝。

还有里面的联合buffer把多个buffer合并成看起来像一个连续的buffer的功能。目的也是在维持代码抽象性的前提下,减少没有必要的拷贝,提高性能。这些都是数据结构而已,很好理解也不是问题所在。

这次主要咨询的是它提供的非jvm托管的堆外buffer以及堆外基础上设计的bufferpool。也就是我提到的还要开发者自己管理引用,不会被垃圾回收的那些东西。个人感觉是jvm不够好而无奈做的设计。原本以为你已经看透了它其实走了弯路。看来实际可能说的不是这个。

0
今幕明
今幕明

@乌龟壳  @talent-tan  坑爹就找osc他爹 @红薯

大清早看到你们两pk bytebuffer,确实也是我的疑惑,持续关注!

0
talent-tan
talent-tan

另外,兄弟也可以看一下这个国产框架,我没研究过,但看起来还不错,另外这个作者说了他为什么要创造他这个框架

http://git.oschina.net/helyho/Voovan#project_comm_title

乌龟壳
乌龟壳
回复 @talent-tan : FYI https://blog.twitter.com/engineering/en_us/a/2013/netty-4-at-twitter-reduced-gc-overhead.html
talent-tan
talent-tan
回复 @乌龟壳 : 厉害!我一般只有某个问题解决不了了才会去翻开源作品的源代码,平时很少看,我一般喜欢看各种helloworld^_^
乌龟壳
乌龟壳
好的,有空都拜读下
0
z
zhuzhua
该评论暂时无法显示,详情咨询 QQ 群:点此入群
0
z
zhuzhua

另外t-io,就不要通过诋毁netty来抬高自己了,netty有太多细节,是通过对apache mina的不足进行改进的。不考虑极限情况和实现细节,一定会出问题,这也是我从mina转到netty并且只使用netty的原因。

0
m
mr_liang0

引用来自“zhuzhua”的评论

原生的bytebuffer屎一样,你多用用就知道了。缺少好几个必要的属性,需要自己去计算。

netty在其上封装了一层,提供了这几个需要自己计算的属性,用起来不再那么的绕。。。

而且只有使用bytebuffer,或者netty的bytebuf,才能够实现缓冲区服用,不然性能烂的

像屎一样,做通信的都懂。

首先你就没看过netty的源码,你以为netty不过是在原生上封装一层而已? 好好读读源码才好意思说话,不然很容易误导人

0
m
mr_liang0

只是几个utils,我真的快笑死,好好学,好好看

OSCHINA
登录后可查看更多优质内容
返回顶部
顶部
返回顶部
顶部