@eltonto187 收到，谢谢，v2 上发过来的我都特别喜欢，来信必复：）

@e9e499d78f 还有一点，个人觉得说不说不太影响大家的决策的是，数据其实是一个横切的角色，其实业务具体内容并不那么重要。而且一定程度上，我（们）希望数据可以自己说话，对业务的具体细节了解越少越好。手工特征工程在天量数据的时代其实是一件不 work 的事情。很多同学靠堆时间挖特征打比赛，冠军介绍说“我挖了几个特别重要的特征...”，这其实......

@e9e499d78f 我都会啦：）公司包装一下也还有拿得出手的，也有好多小伙伴在 v2 潜水啦。但正如我回复 @liprais 的，公司本身不愿意宣传自己，“己所不欲勿施于人”，我不好破，但你入职一个公司，你终将必须了解它。

其实，很多工作可以不是冲公司去，冲人的可能是一个更佳的考虑。个人以为，同事和小环境的作用要远高于公司（和大环境）。

我问我自己：一个工作你要干一辈子，你会选什么样的工作？答案是：和一群喜欢的人做一件喜欢的事。

钱多不应该是你去阿里的理由，同事好可以是你去阿里的理由（但领导可能糟心啊......）；名气大不应该是你去阿里的理由，做最好的技术好可以是你去阿里的理由（但夜夜撸代码到转钟伤身啊......）

@ilittlesun 公司一般小司，介于传统行业和互联网。因为公司一般也不宣传自己（所以，hr 只在什么智联 /英才网找人，欲哭无泪...），我想想还是隐其名，但可以在沟通时告知。

其实公司就两类大的和小的：去大的可以考大厂名声，去小的更多的只能靠自己。这似乎上学类似，但不同在于，工作要选择决定你的生活和事业，学校更多意义上是个缓冲。

@liprais 是的，所以 WTF... 但参考了 v2 的一些招人帖子，比如： 墨刀（ https://www.v2ex.com/t/442591 ），（ https://www.v2ex.com/t/450732 ）。互联网公司常态，令人心酸...

老黄很无辜。。。。。。

大清早，赞，帮顶一个吧！ Netty 和 Norman 还是不错的：）挺好，我也是该琢磨琢磨写本书：）

@zhangyifei216 谢谢， c++1x 还是不错的，期待 c++20:)

@hepin1989 reactivestream是旧酒新瓶，但凡做过message系统的大抵是无视；akka-http也是akka进一步扩张的需要，这对于所有项目都是类似的，能理解，静观其变吧：）

DSL，作为一种“糖”，本身对开发者是友好的，但前提是不影响性能和审美。“糖”，在使用者认识了本质以后，会觉得是一层纯粹的低级把戏，在垃圾回收类语言，是垃圾产生的原罪。所以，在架构上会和内核API分开。也所以，“糖”类工作目前处于比较低的级别，但我乐见以后的社区...

AIO是一个较长的话题，AIO在一些语境被范化为提供异步IO的完整实现，在此语境下，NIO2称为AIO也无不可。Epoll只是提供（IO）事件通知的设施，和AIO没有直接关系。通常，加上一个线程池的项目就可以开始宣称自己提供AIO了，于是有了不少拙劣的AIO实现坏了AIO的名声，以至于很多开发者不知道他们到底需要什么东西来支持他们所需要的高并发后端。

OK， 既然考虑换工作，完全可以考虑我司，我们把未完待续的谈完，哈哈：）

上下文太少了吧。

另外，用ivy的，有点作。。。

@bianzhifu 好，谢谢:)

@hepin1989 Hi！ 在背景密集更新！：）等月底想写一系列文章，然后同步上去，中文版本准备在v2的Java板块首发，虽然v2的这些板块一直很冷：）TechEmpower的评测一直在重构，而且一直没支持Java8，我暂时无视：）

现在多了不少新东西：

1. Buffer做了重构，escape analysis相当友好
2. znr加入udp和多播
3. tcp支持异步数据报（udp）
4. http支持pipeling，深度为64（TechEmpower评测参数）时，通量比Netty大28%，同时已经能在我的移动i7上饱和万兆网。更大的深度就不测了，怕Netty落后太多。。。
4. mini-overhead and zero-garbage logging API，通量已经饱和主流SSD（～500MB/s）。如果你在等一个和高性能server匹配的logging实现，那她是你想要的.(and forget log4j2!)
5. 重新开始和完全审计的加密及SSL库，对Heartbleed说NO！优先支持了x86的硬件加密，暂未支持的offload到libressl。OpenSSL is Dead, Long live Java！
6. 除了重塑Java基础外，未来的一个重要发展方向是分布式(计算)集群。我们已经改造了部分Cassandra...

我现在进入一家创业公司，公司某种意义上赞助了Landz，所以我们将走的更远！

还在成都？是否有意来我司？如果地点有问题，我觉得是可以讨论的，地点我认为不是问题:)


最后，那贴我不想“挖坟”，所以没回了：）在这回复一下：
其实Norman技术能力真心还有很大提升空间，但人确实很不错。几个月前Norman提到的AIO，指得是Linux的Kernel AIO，而非你意识到Java的AIO（NIO2）。

@phun 那你需要一个云控制器：）虚拟机应该会使用不同的技术，估计需要一些和具体虚拟机绑定服务堆栈。

关键是，你想干什么？

@macemers 放眼美帝，Java始终还是最“火”的。贵姓？

@bianzhifu 我司后端最欢迎养家男！做手游，不如玩桌游，云风skynet也不如我大matrix：）是否有联系方式？

@hepin1989

感谢，我是有信必回。

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

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

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

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

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

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

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

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

感谢，这两天是上来瞅了眼，但仅仅是看到首页没有人@我，就没有深入看。我自己也不想挖“坟”，自己顶自己很无趣。刚看到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上持续维护）给予理解。

@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的架构值得大家一看。