Java8 开源后端项目寻赞助或合作

[jinmingjian]

大家好，我是一个开源后端项目（LANDZ）的创建人。因为本贴不是讨论具体语言，该项目也没有正式发布，我暂将此信息发布在这个节点。


该项目上周实现了“自我驱动”，也就是项目的网站使用LANDZ自己的web栈运行，项目的网站在： landz.org
（run在米国的独服上，最近一周来联通访问都很慢，据信海缆未完全修复）
（另：页面尽量做到responsive，但小屏幕访问可以预见会有些排版问题）


1. 简洁。基于Java 8（和“可以在Java8上运行”是两个概念，本项目应该是全球第一个Java8使用比较充分和成熟web栈项目，但我karma很低，发HN没有意义），Java8在源码层支持函数作为第一公民，可读性接近动态和函数语言（大家有意见的话，我们可以探讨）。

2.高性能。该项目提供如下API：
A. Channel API提供wait-free/lock-free的线程间通讯（ITC）。其中，HyperLoop提供一个数据结构版的（简化）Disruptor RingBuffer，其roundtrip延迟比Disruptor小50%到一倍，最大通量相近;再如，MPMC提供第一个开源Java领域的无锁多生产者多消费者队列的实现（目前我所见过2个其他实现都有严重的潜在多线程bug），其不竞争情况下在mobile i7上即能提供每秒50M端到端消息，高于AKKA的AbstractNodeQueue（MPSC队列）。
B. 无锁/零复制/零垃圾的线程安全OffHeap内存分配器zmalloc。在单/双线程测试中，分配/释放速度比native的jemalloc/ptmalloc更快，是Netty ByteBuf的20倍以上;
C. 基于zmalloc的Buffer API，支持不检查边界，比Netty ByteBuf快30%;
D. 基于JFFI的ZNR（Z本地运行时库），提供比传统JNI更快和更干净的系统调用及Sockets栈支持（只支持Linux/x86-64）
E. 零overhead的契约API和异步logging API（未发布）。

3. KISS和可组合的API。
A. 层次化API设计，既有底层的性能，也提供类型安全接口，避免过度工程和隐藏。

4. 工程维护和运维。
A. 支持模块。将来会有一个滚动更新（rolling update）的模块仓库。
B. 基于Nashorn引擎的脚本（第一公民）支持，提供构建，测试，部署（这3项已初步支持），监控和运维支持。

5. 完整的支持REST的HTTP栈 - Z-stack
未发布。但特点有：
A. 手工的HTTP消息解析器，比Netty的3倍，比nodejs的5倍（比较的是修改过的java移植版，但我相信nodejs的本尊快不了多少，因为修改过后已经比原来快了1倍，还没有加callback）
B. 定制的lock-free异步线程池
C. 768M堆设定下，进行TechemPower测试时，无fullgc，younggc停止时间（stop-time）小于总时间的千分之1（需要在可用性上做平衡，REST栈并不是全OffHeap设计，但TCP栈已可以做到长时间无GC）;
D. 在基于TechemPower测试集的plaintext本地测试中，通量是Netty的1.3倍（延迟有相同幅度改进）。（注：在TechemPower的测试中这项测试中，前几名通量近饱和，所以区分度不大；需要区分的，请看round 9的Peak硬件上的测试结果。）


和一些项目的比较：
1. Netty
Netty有10年的历史，很多中国开发者知道、使用或分析这个框架。Netty的设计属于典型的框架，在其之上的应用需要继承一些类和实现一些方法。Landz在设计上恰与Netty反向，Landz强调API的可组合，所以，Landz之上的应用是从高到低组合不同层次接口来实现。Netty在多线程方面，除了通用IO线程池方案，并无明显优化，其其同步方式主要靠AtomicX类（类自旋锁）和同步关键字。最新的ByteBuf分配器使用同步关键字作为全局池访问的同步机制，在多线程测试中效率低下。Landz强调多核/可伸缩/可组合的架构，同时提供工程上的支持（比如脚本），其意在重塑Java后端工程（当然现在属于YY），这和Netty完全不同。

2. 云风的skynet
c语言框架。有些设计思路异曲同工。虽说是游戏服务器，但不以通量为其设计目标。同时，Landz强调无等待/无锁的多核可伸缩架构，但我印象中skynet里主要是用锁。

3. 陈硕的muduo
C++网络库。本身是有是思想的。作者明确说明不以性能为设计目标，但其测试显示性能比ningx要高。其强调了多线程，但我仅仅看到了一些IO线程通用设计说明。其具体通量性能可对比nginx在TechemPower测试中的排名（http://www.techempower.com/benchmarks/）做参考。

（列出上述项目，仅因为我印象中v2上有人提及，想必有一定群众基础。其实现实中还有很多类似项目，比如techempower上的若干，你会发现c+lua不只是skynet一家开源）


最后，想法：
1. 该项目的方案，在去年年中其实和v2上一位创业公司的总监聊过，人家估算我这个项目要做2年（也可能是人家架构师不喜欢我），没有谈成。当然我知道在中国做开源是件很难的，也感谢这位负责人至少在我们交谈中能很认可开源。

2. 项目做到现在，我希望在v2上（公司无论大小地点）能找些合作或赞助。我可以承诺的是，比您现有业务更大的并发及通量（两者并非一回事，同时并发这个概念也很有说法）和随之而来的更少的机器。其结果不一定涉及钱，也可以是您愿意LANDZ在其主页上留下贵公司的名字。

若有意向，可联系我，感谢：jin.phd at gmail.com

[terrytowne]

看起来像是Netty + Vert.x + Spring Boot的综合体。
Java 8看起来还是一个过渡性版本，要搞FP还是使用Scala、Clojure。

项目太实验性，会投入很多和收益很少……

[jinmingjian]

@terrytowne Java8在Java演化中不可能是过渡性。相反很多规划中的Java9依赖Java8的革命性。

我做过Scala的表示层解析器，其可以表达的复杂远超一些的纯fp语言。更深层的讨论恐怕太主观。

至于，项目实验性不知从何谈起，很多技术都是高性能Java讨论的热点，只是中国开发者很少讨论。其实landz 在春节做过一次发表，Netty的韩国哥哥已经对他们自己产品Bytebuf性能做了点评。

但我一直有个想法，为什么在一门主流开发语言上韩国人开发的框架可以看到中国人时不时贡献补丁，而中国人却没有？我想，你说的“收益”确实是很好的解释。

[jinmingjian]

另，Jboss已经使用全新的Undertow；play！框架正准备从netty迁移到另一个Scala REST栈。我虽然对比的是NETTY，但并不是说Java后端在设计上必须以Netty为榜样。

其实，你说这几个框架如果是个裸的，我不知道能干什么，但Landz的最基础的kernel支持库的方式使用。我写的所以Api除了网络层的，全在kernel里。

[feilaoda]

写了不少代码啊，貌似代码不全，无法评价。

在真实环境用用，用的人多，才能流行。

[terrytowne]

@jinmingjian Java基因里面就没有Lambda表达式，你也可以看到Scala融合的多么困难。在短期内，Java 8引入Lambda表达式的作用只相当于语法糖，深层次的革命还远远没有开始。

Java作为一个工程型语言，对于热点往往是不敏感的。你若是能做成OpenResty那样的项目，自然有人来捧你。

Java 8 引入Lambda，Java 9会引入Jigsaw，比对Java 5的Generic、Annotation变革到Java 6才成熟，我猜这些新功能到Java 10才会流行。

Java虽老，变革不小，且学且观望吧~ 没必要太着急……

[pythonee]

说的这么多，能不能一句话介绍一下

另外，看着挺感兴趣的，希望可以深入了解下

[terrytowne]

当然，这个项目看起来还是很屌的，有空会学习；也希望项目能找到投资和伙伴，能让它继续下去！

[blueware]

明天上班发邮件给您。

[thinkxen]

过两天我可以赞助一台香港vps主机。

[jinmingjian]

@terrytowne 你说了部分事实。Jigsaw的难产，是件很尴尬的事情，其实Jigsaw设计的已经比较简单。但对于巨大单一的Java运行时来说，困难还是不少。Java8推出了compact profile，我机器上cp1的大小是20M多点，不知比其他语言的运行时大小如何？再比如，你提到Annotation，Java8引入了type annotation，这个特性较少被人提及，但其实是一个潜在的很有用的设计，它允许annotation一般性的出现在代码各个的地方，这就允许对代码中的很多地方进行约束和检查。java8的革命性，我以为是超出Java2以来的任何版本，但我承认新功能在Java圈里流行相当慢。Java社区也能引领前沿，正是我的一个期待。

> Java 8引入Lambda表达式的作用只相当于语法糖。
1. 对于newcomer将lambda看成语法糖是可以的，但lambda的实现原理并不是传统的匿名内部类。这利用了Java7一项字节码增强invokedynamic，该增强为JVM上的动态语言准备；有意思的是，其性能比匿名内部类略强，有兴趣可以看Hotspot VM工程师的一个分享：
http://medianetwork.oracle.com/video/player/2623576348001
这主要2点原因，JIT优化和匿名类（不同于“匿名内部类”），具体展开就多了，我愿意以后在v2的Java节点做些详细介绍，包括一些前沿的做法。

2. Scala和其他的JVM语言其实也收益于Java的改进。
这里有关于Scala使用methodhandle的讨论：
http://stackoverflow.com/questions/14285894/advantages-of-scala-emitting-bytecode-for-the-jvm-1-7

我承认Scala和其他的JVM语言有很多有趣的特性，但从工程角度将这些特性，是否是必须的，还可以商榷。


OpenResty，春哥的事迹有所耳闻：）Techempower的测试里就有OpenResty。我不知道OpenResty对nignx的改进有多少，但nignx本身的epoll模块实现，我撸过一眼，事件处理使用了锁，Techempower的通量测试成绩也低于我的预期。


感谢你的鼓励，我其实是受了投资的“刺激”：）我原计划是准备在v2发第一贴找些有兴趣的同志一起做些事情。我无语的是，种子投资要种子用户，当作为种子的项目它还没有生长出来，种子用户又从何谈起？当然这些是另一个话题：）

最后，不管如何，项目开源会继续，Landz会在round 9过后的某个时刻加入Techempower的测试，原因在测试的论坛上我有说明： https://groups.google.com/forum/#!topic/framework-benchmarks/HH2K8xDut3I

现在committed的部分不包括HTTP栈，同时TCP模块的线程池设计属于实验性的，没有针对通量优化，这是目前可预见的坑。其他部分无坑，有各种测试保证，landz现在的各种测试只比我见到过的开源软件严格，里面甚至还有Disruptor和JDK的bug测试。

[jinmingjian]

@blueware 感谢：）

[terrytowne]

@jinmingjian 十分佩服！期待项目的进一步开源！

[jinmingjian]

@thinkxen 真的太感谢，感谢！其实，我是希望v2的程序员们，能帮我项目在github点个赞，哈哈：）能有以上2位回复，我想v2这个贴已经值了。

我长期潜水v2,最初是从google vps到v2，我觉得v2是个有理想的社区，有时技术性太强我都担心对v2未必好：）

如果 @Livid 愿意，我愿意在异步logging完成以后，帮v2以LANDZ的方式改造下v2（不谈钱），虽说在大规模DDOS面前都是扯淡，但我相信其抗普通攻击和应用内监控分析能力应该能提升不少。

当然，我不建议程序员换语言。所以，如果L大是pythoner或dartisan，请忽略建议。如果一种语言舒服，为什么不用？性能只是诸多因素中的一个方面，因为性能换语言很可能得不偿失。

[feilaoda]

@jinmingjian 用LANDZ改造v2不现实，你可以实现一个类似的出来，重造轮子，是可以的。
当然，如果实现类似telegram、textsecure的服务端，是最好了。

[jinmingjian]

@feilaoda 感谢。我并不喜欢重造轮子，我喜欢的是“造更好的轮子”。我还看不出改造v2不现实技术上的原因。难易和现有架构有关。当然，很多其他任何原因都成为不现实的理由。

这使我想起，春节后我回来，我纠结了几天要不要重写个HTTP的Parser，现成的那么多Netty的，HTTPClient的随便拿来一个不就成了？首先，Netty耦合的很紧密，codec/encoder/decoder/util套了几层，把这些提取出来是可能的，多余的垃圾怎么办？这不是LANDZ做事情的方式。其次，Netty的实现方式并不真的高效，只是有些讨巧，Nodejs的parser在合规性上远严格于Netty。最后，我在优化Nodejs的parser时，发现techpower测试靠前的框架都是自己写。易于掌握和完整控制，是LADNZ的哲学。而且写完后，你会发现，写不一定真的复杂（当然其实还是很复杂的）。我承认为为测试优化这并不值得提倡，但这项优化是具有一般性的和普遍受益，它其实很重要。

Landz其实赞成合作，未来有可能和其它框架合作，且行且看：）（如果有，我会在v2上报告下）

但你说的telegram之类，确实是LANDZ的最适合的场景，因为这种消息类服务始终是渴求性能的，最近WhatsApp的架构值得大家一看。

[Livid]

如果一个网站项目，最后会长到几万几十万行代码的话，要考虑的因素会很多，我就稍微提两个我觉得重要的（不是全部）：

* 一个好用的模板引擎：目前 V2EX 在用的 Jinja2 我很满意，功能该有的都有了，extends 机制很利于代码的重用。我相信重用程度越高的代码越有价值。
* 一个好用的异步运算框架：一些复杂的但是又不需要立刻知道结果的功能，需要有一个足够好用的异步运算框架来处理。如果页面上有一些很重的东西，这些东西不仅会拖慢网站，也会是一个很容易被攻击的弱点。

关于抗攻击，虽然说安全的原则之一就是尽量不要讨论做法，但是我还是想说，防御应该尽可能放在离用户近的那层。

那么多大型网站在用 Java/C#，我相信肯定是有他们自己的道理的。在美国这边，收到的大量简历基本上都是 Java 的。

我个人觉得，对于一个新框架来说，或许需要的是用它做一个用户确实会喜欢和依赖的应用，如果这个应用成功了，那么这个框架也就成功了。

[hepin1989]

@jinmingjian 您好，我很熟悉您这个头像，您的英语很好，涉猎很广也很深入，我看过您在netty的一个Issue上的讨论，很透彻。
我也给Netty提交过代码，对于您的框架，我觉得如果要开源参与，那么至少先得开源，然后作者自己很积极，同时提供更好的文档以及贡献代码的规范以及您的设计思路和里程碑。
再者还要有良好的Issue管理以及审核标准，同时要提供良好的列子程序。

如果您想建立一番不同，那么肯定是得下一番功夫，包括代码质量以及社区，特别是社区，得靠经营的，而经营社区可能比写代码更难。


Netty 以及Spray我觉得时比较具有代表性的，但是看来您的理想是做个类似Play但是比Play更加强大的框架，我相信您肯定可以做到，但是一个人的能力和精力都是有限的，可能群体的智慧更加强大。

目前Netty4比Netty3改进了不少，比如更好的ByteBuf以及更好的线程模型，以及更少的GC。而且还开始通过JNI来提升部分地方，Netty的Codec的确是需要学习和借鉴的地方。对于Spray，您也知道性能并不差，现在又合并到Typesafe啦，马上作为Akka-http发布，会更加的牛逼起来。

目前您在Github上的z-stack
https://github.com/landz/z-stack
最后的提交已是两个月前的事情了，没有很好的Dev Guide以及User Guide，WIKI页也还差点，Issue的管理也有点松散。

还有一句话有舍有得，如果您的框架可以全部开源，相信在初期可能您没什么好处，但是群体是会扩大的，也会有人慢慢的参与进来，当然您损失了您的代码，但是在后面，您会得到足够的光环的，这就是您的得。

还有一点非常重要，如果想要成功，您必须要让您的框架简单，简单和高级的特性都好用，良好的文档，例子以及社区，感谢分享这么多东西，祝您成功，如果Github放更多的东西出来，相信慢慢参与的人就会多了，还有，您可以推送您的sample到techempower，相信会发光的。

[hepin1989]

您的官网要翻墙才可以出去，在看您的官网，不过您网上说的techempower的跑分，我倒是没看到您的landz。。

[hepin1989]

```
最新的ByteBuf分配器使用同步关键字作为全局池访问的同步机制，在多线程测试中效率低下。
```
这个需要更正下就是目前已经改进了，每个线程有自己的池，自己没有了才去全局池，才需要同步下。

[hepin1989]

```
除了通用IO线程池方案，并无明显优化，
```
还有这个，因为NIO的JDK实现是有锁的，所以他们写了个Native的，然后里面没有锁，因为他们的线程模型保证了不会竞争，所以在Native的实现里面没有锁，也算个优化吧，还有全新的Bytebuf也算吧,codec也优化了。

[hepin1989]

话说您可以用您的框架做个类似V2ex的网站来作为您的Group，google group的访问的确不行。一方面可以证明您的框架OK，另一方面也可以有新的思路。

[jinmingjian]

感谢，这两天是上来瞅了眼，但仅仅是看到首页没有人@我，就没有深入看。我自己也不想挖“坟”，自己顶自己很无趣。刚看到hepin1989在github开了issue，就必来自v2，想进来看看，没想到L大也留了言！：）

@Livid
这满满都是经验啊，再次记下！

其实也有考察：）模板是个很有意思的话题，从JSP到xxxJS，有很多层次都试图用自己方式解决这个问题，我其实不想将项目做成框架，所以我暂时（其实是没有时间）倾向于，表示层的东西可能放在表示层（客户端）做更好，而且JS似乎已经有很多不错的表示层（模板）框架。

异步是很关键的，也是框架是否高效的一个重点。很多框架并不在意这一点，这里很多原因，我希望有时间我可以具体写写什么会这样，以及可以怎么样。

@hepin1989
我看你给Netty提交过bug修复？90前的后生可谓：）而且作为四川女婿的我也要给你点个赞：）

应该不用翻墙，不排除你的四川运营商有什么问题？只是个技术网站的静态网页，应该不至于。


Spray我的确研究过，前文我没点名，但正是Spray有自己手工的HTTP，最后促使我决定也写一个更好的轮子，不然网站进度不会拖到4月：）

Netty的Codec并不值得学习，甚至Netty整个框架式的架构方法，也从工程角度讲，不值得提倡，当然这是我个人看法。这些都是比较上层的东西或者说比较虚。真要学，Spray甚至Undertow都比Netty强。

关于github上的文档，感谢你的指出，确实是这样。原因其实我说了，但没有说太明白。wiki倒是反映了要或已经做的东西。在此，我合并你说的ByteBuf和线程模型在此给出一个说明：

1.
ByteBuf如你说所在最近进行了一项改进，优先在一些本地分配。我不知道你测试过了没有。但据我测试，性能不仅没有明显改进，allocate时还有严重退化（landz上有关于netty的测试，你可以自行比较）。我并非Netty的义务测试员，在此我暂不多谈。分配器是一件很难做的东西，据我所了解，jemalloc的一些关键设计，Netty并没有实现。除了线程安全问题，就性能看，ByteBuf还有很多明显设计败笔。Netty的ByteBuffAllocator是我看过的netty缺陷的最大的一堆代码。Netty意识到了在on-heap上分配Buffer带来的严重的GC问题，但它确实没有做好这件事（或者至少离理想水平的差距还很大）。

“线程模型保证了不会竞争”其实是很容易的，问题是这种线程模型是不是最优？你的用户线程是分离的还是和IO线程合一的？如果用户逻辑阻塞怎么办？如果你看了昨天淘宝某位哥哥在Netty上的帖子，你会承认Netty现在的这种模型恰恰有严重缺陷。你可能也知道，现在Netty正在讨论FJ池的可能性，这其实是我去年年底已经思考和研究过的，FJ确有其高明之处，但不是银弹，而且用不好会很“扯淡”。我现在有个还在进行中的通用异步池设计，可以类比FJ+AKKA的Actor。。。如果告诉你，连star300多的github项目都使用错误的lockfree队列实现（而且是经我提醒改过一次），连淘宝高工发表在Infoq这样网站的lockfree算法分析文章都有错误，要做好一个原创的、通用的、高效的池，大家都能理解，“想必是件极难的事”（OK，我应该说人话）。

2.
之所以新的代码没有发表，我就更明确的说，因为框架之间也在竞争。不能说ByteBuf的改进是因为Landz的zmalloc的竞争，但我看出，最近Netty展现出了快速的学习能力。我在Netty的讨论组里，Netty的两位全职作者也在landz的讨论组里，这就是事实。那什么时候commit新的代码呢？我猜在5月底左右。其实现在已经有很多好东西，当然也有一些重要改动，这也是开源的魅力。但最后，我相信你能对我的种临时性的发布策略（1.0发布后，landz将在github上持续维护）给予理解。

[hepin1989]

@jinmingjian
1,google group我这里是打了Host补丁的，不过还是会遇到偶尔访问速度啊，或者其他的一些问题
2,netty的Codec的好的地方是他又很多常见的Codec，也很好扩展，如果您要推广，那么肯定得多写几个常见的Codec
3,netty的Bytebuf主要是在Iobuffer的时候使用，快很多。有个Netty Best Practices with Norman Maurer.mp4,在Youtube上，您可以看下。
4,如果Netty的Allocator有明显的缺陷，我想如果您提交下补丁可能对国内那么多用Netty的人是个帮助，也是个好的切入点，印证了“我想改进Netty这个轮子，我也改进了，但是我打算制造一个更好的轮子”。
5,的确打算用FJ，不过既然不是银弹，所以还有其他要考虑的地方，线程模型的确是非常难的。
6,好吧，您觉得有竞争我就没办法了，但是我建议您有个更开放的心态，Netty没有开放出来的，只有部分的Codec，但是基础代码是开放出来的，我想如果您以一个开放的更加包容的心态来弄的化，可能更好，当然如果您可以狠狠的鄙视Trustin和Norman一把，那么我们也算沾光啦。就目前我已经很少使用Netty了，而是采用的Akka+play来做，因为开源，以及开放的开发，可以更好的参与以及获取项目的最新进展，您的东西的确好，但是大家看不到，我昨晚花了时间把您的Google Group的帖子看完了，也大概浏览了下代码，帖子写的很好，但是代码吧，至少写法上不是很规范，注释掉的代码没有清除掉，没有开头的声明也没有太多的注释，所以对于想要一窥的人来说，可能也是多少有点不太方便吧。
7，不管怎么样，我还是很关注和支持的，但是我还是觉得，您给Netty发下PR可能可以获取更多的关注。

[hepin1989]

还有一点
```
异步是很关键的，也是框架是否高效的一个重点。很多框架并不在意这一点，这里很多原因，我希望有时间我可以具体写写什么会这样，以及可以怎么样。
```
异步不一定是高效，这里逻辑有点点。。。

[hepin1989]

@jinmingjian 楼主对发版本的想法可以用一句话来形容：“不鸣则已，一鸣惊人！”还有那个HttpCodec的ThreadLocalPool，我直接感觉和Play-java的HttpContext差不多了，都这么用，不过TL是有消耗的，真的可以优化。而且您的ByteBuffer提供的功能的确不多，以及您也没有按NIO的方式来实现Native。
当然我看到的都是您的老代码了，支持了。

[jinmingjian]

@hepin1989

感谢，我是有信必回。

我并不喜欢重造轮子，我喜欢的是“造更好的轮子”。我正是觉得韩国哥哥开发的netty，是离软件工程的最佳方式差距还很大，所以才有了landz。两个项目开发理念，甚至开发者的口味，真的差很多。

不瞒你说，我小范围发布之初，和韩国哥哥Trustin Lee有过通信，开始大家是觉得可以合作的，但后来，我指出Netty在工程设计上的各种问题以及如何改造之后，人家不联系我了：）我的理解是，你至少可以回一句“对不起，改动太大，不可行”，都让人可以接受。为什么不说话呢？此时，你会不会上杆子贡献补丁呢？

中国开发者完全可以做的更好，为什么不呢？

当然，这里扯“爱国”牌，不太对。但是，不破不立。按你的意思，JBoss不应该开发Undertow，Play也不必换到Spray。为什么我不想解释太多，因为我预计到，“应该有个开放的心态”这个大帽子很可能会扣上。到现在还没有，一可能是我觉得是v2上的程序员给我面子，二可能大家不太care这个项目：）但你提出来了，我还是想回复一下。

至于他家ByteBuf，我自然相信比以前在堆上分配要强。但你要看和谁比？而且快还是慢，应该由测量来说话。我所说的具体数据，我必有开放的测试让大家都能验证。如果你有横向测试代码，我愿意帮你分析一下（虽然，我没有太大兴趣）。

Norman的ppt我看过，还好，但对熟悉网络io的人来说，属于比较直白的介绍性文字。

异步确实不一定是高效。因为，这东西太多在此无法展开。通常的认识是，同步调用（也就是现在大众程序员使用的方式）难以规模化到多核。当然，异步概念本身也有人较真。异步、并行、并发、非阻塞。。。我猜你喜欢AKKA的Actor，但你有没有思考或遇到过Actor有没有什么问题？出了问题，你一般是怎么处理？如果要你做，你能不能做的更好？

我觉得，你和我一样是位爱思考的程序员，如果这个帖子能找些有相同兴趣的人做些事，我觉得是它最大的用处。

[hepin1989]

@jinmingjian
1,我倒不是说您在造更好的轮子不妥，而是目前别人的轮子修修补补您也可以发现更多的问题，所以如果你有空，可以提交下PR，按照别人的思路，在别人的工作上改进，而不是推倒。

2,Trustin那人可行吧，但是我感觉他不喜欢别人觉得比他聪明。您可以看下他目前Netty 还是Open的Issue，然后您可以试着关闭下Issue，也就是提交PR，还有呢我觉得还是不要介意别人没有回复您的邮件好，当初我问了很傻比的InstanseOf的性能别人都回复了，所以我觉得应该不是太大的问题，如果别人忘了回复邮件或者其他的通信方式，完全没必要介意，毕竟开发者不是他一个很多人都有合并权限的。

3,的确可以做得更好，但是妹的，又是房贷又是老婆孩子，还得有自己的生活吧，所以，时间的投入可能的确不如别人，加之整个环境，所以国内的开源难做和很多其他的事情一样

4,我不是说不应该破旧立新，而是说在破之初，可以有不同的切入点，比如您现在的这个项目，知道的人不多，你可以将您的独特思考以及共享回馈到目前的主流项目，这样也可一石二鸟，多方受益。Undertow我没用，但是Play换到Spray有多个原因，1,Spray用的Scala和AKKA，2,他们好管理以前不好管的线程池，3,他们收购了Spray，但是目前不也没用么，Akka-http在Akka2.4的时候肯定还是实验班，而到akka2.5的时候还不知道究竟如何，何况Akka的ReactiveStream也还没出来，Play项目负责人也说了，可能会提供一个抽象层，Netty和Akka两套Backend。他们目前没换，也说得很清楚，要等到他们的至少和Netty的差不多了再说。他们还是把他们的一些改进合并到了上游，比如HashWheelTimer以及目前对Async-Http-Client的改进，都是合并到了上游的，当然这和你这个不同，因为您另起炉灶，和他们用别人的改进别人的还是不一样的。

5,可能他家的Bytebuf在DirectBytebuffer上的分配不如您的，不过别人的还是很好用的，我看您的接口时Bytebuffer，但是不是JDK的bytebuffer，建议呢就是还是适配大家目前已知的东西比较好，当然这个是个设计上的考量。我倒是不会提交测试代码，因为我自己也没兴趣，现在机器便宜了，可能多个机器的收益更好，更需要考量的是这个框架好用否。

6,其实直白的文字来说，更容易引起大家的共鸣，将复杂的问题用简单的方式讲出来才是高手，他那个简单的PPT不是说他肚子里面就只有那么多墨水，而是他给我们普通的开发者，或者新手在很短的时间内接触和了解netty的机会。比如几分钟内介绍您这个框架如何好，为什幺采用，如果能够打动人，那么就是真的厉害，不是么？一个好的PPT可以煽动人的。


7,我倒不是喜欢Akka的Actor模型，但是它的确让我有醍醐灌顶的感觉。并发的几个思路也不多对吧，多看点，思路也更开阔点，比如Go的http://en.wikipedia.org/wiki/Communicating_sequential_processes 和Akka 的 http://en.wikipedia.org/wiki/Actor_model
都是不同的思路，而且目前Akka加了Eventsource也就是Akka-persistence，我觉得也可以引发更多的思考，对于我们单个开发者来说，可能我们不会用也不会深入某些技术，因为精力有限，但是学习下别人思考和解决问题的思路的确对自身还是有很大的启发，我目前还没有遇到很奇葩的问题，也就是通过别人提供的解决方案没法实现的，所以思考的少，但是如果遇到了，我会去Group 问的。

8,最后的建议就是，做减法，永远比做加法难，愿你的框架做到极致。