作为一个惹出过和处理过一些严重故障的人，我仍然觉得要做好稳定性，最难的并不是技术，或者更准确的说，技术上在怎么做好稳定性，从代码到设计到变更，都有全面的指导思想和原则，包括大家如果去看很多的故障复盘，在改进措施上基本会看到各种类似的话，但这些思想和原则要落地好，是很复杂的话题，有能力要求，还有更重要的是投入要求，而且并没有银弹级产品说做某件事，或安装一个什么软件，就可以保障稳定性了。先简单说说技术上，然后再来说为什么难的不是技术。代码层面关于稳定性的指导思想我之前说过是不是优秀的程序员，代码是最好的证明，优秀的程序员的最大差别其实就是在代码的鲁棒性上，而这个一方面需要极强的能力，看看netty的代码里对各种边界情况的处理就知道要求多高，另一方面则是需要有投入的保障，否则都在赶进度，自然是会把鲁棒性相关的代码放一边，毕竟很多时候这些代码还挺难体现价值的。代码要写的鲁棒，很关键的几点：1.

上周和极客时间、阿里云联合做了一个直播，在这场直播里分享了关于程序员职业发展的话题，这个topic我近几年给一些团队分享过几次，包括在极客时间的专栏上也有讲到过，不过内容层面，关于程序员的职业如何发展（技术专家、具备架构师能力的技术负责人、技术Leader），我的想法确实没变过，:)，把分享的ppt也在这里发下，不过ppt上的信息可能不多。1.

关于EDA的抽象，作为系统架构师，很重要的职责是抽象，在这个演讲里可以看到EDA的抽象：对象上抽象为event、producers、consumer、recorders，交互模式上抽象为point

云原生这个概念已经越来越深入人心了，但对云原生到底是什么，仍然是各种各样的解读，最近对云原生具体是什么有了点感触，写下来分享和探讨下。我现在认为云原生其实是让众多的公司，通过基于云的产品迅速获得在构建一个现在这个时代的应用（是不是有点像AWS一直讲的Modern

这段经历对自己更加深入的掌握在代码逻辑整体的细节层面是非常有帮助的，这对于写要求很高的系统是非常重要的，毕竟对于一个超大规模的系统而言，1%的提升还是可观的。

几个公众号转了我三年前写的，阅读量远比当年我发的时候高多了，感谢呀，那篇确实算得上心血之作了，哈哈，正好最近我在内部在做一个系统设计培训的尝试，有了更多感受，在这篇文章里再来写写。系统设计我一直觉得是远比Java编程技能更难多了的培训，很容易变成务虚课，全是一堆理论，然并卵（想想一堆没怎么做过系统设计的人讲系统设计的课，这纯粹是开玩笑），所以以前从来不敢尝试做这方面的培训，不过今年由于一些情况，决定大胆尝试下，就在内部搞了个民间的培训，结果还真有不少同学捧场，在开始上这门课后，我觉得收获最大的搞不好是我自己，整理思路，从和学员的互动中学习到了很多，能更好的对系统设计的一些方法论进行抽象总结，所以我和这些捧场的学员们说其实是我们一起在共创系统设计的课程

在更早前，我基本觉得拓宽技术视野就是多在网上看看各种的技术文章，多订阅几个高质量的RSS，公众号，但过去一两年，我发现拓宽技术视野也是可以有一定套路的。

的指点下，将tcpNoDelay设置为了false，但这个设置不适用于低压力的情况，在10个线程的情况下tps由3w降到了2k，因此tcpNoDelay这个建议还是设置成true。

一个典型的客户端集群->LB->服务端集群这样的结构中，如客户端采用连接池，长连接的方式，这种设计你觉得可能会出现什么问题？如果客户端采用的是单个长连接的方式呢？如果有问题，你觉得应该怎么解决？

从目前自己的公众号来看，文章的阅读量还得靠转发，希望大家觉得还行的文章就帮忙多转发下，:)

对于单体式架构而言，如果是Java的话，应用PaaS通常就是类似Spring这样的框架，Spring的IoC、AOP、数据库操作的封装、MVC这些基本上可以满足开发一个单体式架构应用系统的技术诉求。

IaaS层经历了多年的发展，这里也只能以我自己所经历的来进行回顾，之所以要回顾，是为了通过过去的发展，来看这个领域发展的动力，从而更好的创新，引领未来。

那个时候做网站真的好赚钱)，可能那样过了个一年左右，做静态的网页就不好赚钱了，也不好找实习工作，于是就开始学asp，写些简单的CRUD，做做留言板、论坛这些动态程序，应该算是在这个阶段接触编程了。

从上面这些引用的观点，我们能看到对于AWS而言，并不是FaaS或者说Lambda==Serverless，而是很多的东西组合在一起才是Serverless，它的最大价值则是让使用者能够just

总结来说呢，我觉得和在之前文章里写的一样，我认为程序员可发展的路线还是很多的，上面写的这三条其实都是可发展的路线，没有孰优孰劣，谁高一等之类的，兴趣、个人优势仍然是最重要的。

还有在做某些系统的设计时，平滑迁移我认为是项目能成功的关键因素，所以在设计原则上我也会写上平滑迁移，确保各个子系统在设计时会把如何从现有迁移到新的结构上放入关键。

在某个大的技术方案里，同样也是几个团队在同一个技术点上都有自己的方案，我最后选择的那个团队基于的判断是：我相信对于公司而言，那个团队才是应该掌控这项技术的组织。

作为技术人员，在刚起步阶段时，首先需要拓宽自己的技术宽度，对自己所做的项目/产品所涉及的方方面面的技术都应该有所了解，另外对于就是学习工程化，让自己真正具备开发商业软件的能力。

分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test，以及和大家一起讨论一些Java问题或场景，这里只有Java细节的分享，没有大道理、大架构和大框架。

阿里JVM团队的同学帮助从JVM层面继续深入的剖析了下前面那个ygc越来越慢的case，分析文章相当的赞，思路清晰，工具熟练，JVM代码熟练，请看这位同学（阿里JVM团队：寒泉子）写的文章，我转载到这。Demo分析虽然这个demo代码逻辑很简单，但是其实这是一个特殊的demo，并不简单，如果我们将XStream对象换成Object对象，会发现不存在这个问题，既然如此那有必要进去看看这个XStream的构造函数（请大家直接翻XStream的代码，这里就不贴了）。这个构造函数还是很复杂的，里面会创建很多的对象，上面还有一些方法实现我就不贴了，总之都是在不断构建各种大大小小的对象，一个XStream对象构建出来的时候大概好像有12M的样子。那到底是哪些对象会导致ygc不断增长呢，于是可能想到逐步替换上面这些逻辑，比如将最后一个构造函数里的那些逻辑都禁掉，然后我们再跑测试看看还会不会让ygc不断恶化，最终我们会发现，如果我们直接使用如下构造函数构造对象时，如果传入的classloader是AppClassLoader，那会发现这个问题不再出现了，代码如下：public

上篇文章中附加了一个最近碰到的奇怪的case，有位同学看到这个后周末时间折腾了下，把原因给分析出来了，分析过程很赞（无论是思路，还是工具的使用），非常感谢这位同学（阿里的一位同事，花名叫彦贝），在征求他的同意后，我把他写的整个问题的分析文章转载到这里。文里图比较多，手机上不方便看的话，建议大家电脑上直接访问http://hellojava.info看。上分析工具VisualVM在解决很多问题的时候，工具起的作用往往是巨大，很多时候通过工具分析，很快便能找到原因，但是这次并没有，下图是VisualVM观察到Heap上的GC图表。从图标中可以看出，Perm区空间基本水平，但是Old区空间成增长态势与YGCT时间增长的倍率基本一直。熟悉YGC的朋友都知道YGC主要分为标记和收回两个阶段，YGCT也是基于这2个阶段统计的。由于每次回收的空间大小差不多，所以怀疑是标记阶段使用的时间比较长，下面回顾一下JVM的垃圾标记方式。JVM垃圾回收的标记方法-枚举根节点在Java语言里面，可作为GC

分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test，以及和大家一起讨论一些Java问题或场景，这里只有Java细节的分享，没有大道理、大架构和大框架。