程序员的成长路线

工作这么些年了,看到了各种各样的程序员,也看到了各种各样的成长路线,说说自己的一些观点吧。

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

在工程化和知识宽度达到一定阶段后,需要开始根据自己的兴趣和工作内容有所选择,主要是加强在某一领域的技术深度。

在技术深度达到了一定阶段后,需要对自己做出一个选择,就是偏业务方向,还是偏基础技术方向。

偏业务方向的技术人员,我认为做的好的表现是:
1. 对业务发展的未来有一定的预判,有商业敏感意识;
2. 能对复杂的业务进行合理的抽象;
3. 在系统的设计上能对未来业务的变化有一定的预留处理。

偏基础方向的技术人员,我认为做的好的表现是:
1. 能结合业务的发展趋势对基础技术的方向有一定的预判,避免业务发展受到基础技术的拖累;
2. 对业界的技术发展方向有自己的认知和判断;
3. 在对应的基础技术领域有不错的技术深度。

结合自己的特质以及当前的一些状况,做出一个选择,重点发展。

而再往更高阶走的同学,通常就会出现一种新的角色,就是成为团队leader,做为一个技术团队的leader,无论是业务的还是基础技术的,在技术能力上还是不能差的,尤其是判断力上,另外,作为一个团队leader,就意味着承担了团队方向的判断的职责,一个团队的方向基本会直接影响到团队所有成员的未来,以及所支持的业务的发展状况,所以对于一个团队leader,我觉得最重要的能力就在方向的判断上,然后是根据方向的判断的组织建设(团队搭建,人才识别、培养、招募等)能力。

如果不是往leader方向呢,那基本就是往架构师方向为多,架构师的话,在至少一两个领域的深度外,对广度的要求非常高,还有同样就是判断能力,无论是业务架构师,还是基础方向的架构师,领域的知识宽度是非常重要的,意味着能做多大范围的事,判断能力会体现出一个架构师在做一个架构设计时重点是怎么判断的,在有限的资源和时间情况下取舍是怎么做的,对未来是怎么做铺垫的,以及TA对事情的技术控制能力,一个好的架构师在技术风险的控制能力上必须是非常强的,例如一个强大的基础领域的架构师,应该是可以很好的控制跨多个专业技术领域的技术演进。

还有一种是往专业技术深度领域方向走,例如内核、JVM等,这些领域是真正的需要非常深的技术功底才能hold的住的。

还会有其他例如转型往业务产品方向等发展的就不在这说了。

总而言之,言而总之,我觉得在整个成长过程中,兴趣是最为关键的,所以follow your heart非常重要,只有在有足够的兴趣或梦想的情况下才能产生很强的自驱,没有足够的自驱我觉得在技术领域基本上是不可能走到高阶的,除了兴趣外,自己的优势也要判断清楚,每个不同的方向,我自己认为还是需要一定的天分的,而所谓的天分我觉得就是对个人优势的判断。

=============================
欢迎关注微信公众号:hellojavacases

公众号上发布的消息都存放在http://hellojava.info上。

技术人员的情结

每个技术人员都会有技术情结,或多或少而已,语言情结,框架情结等,这篇文章就来说说自己的技术情结和看到的一些人的技术情结的事。

我自己对OSGi算是有情结的吧,很多年前在上海工作的时候,偶尔会去参加一些meetup,看着讲topic的人都觉得好牛,好想认识下,但相对还是会比较困难,直到我接触OSGi,并且写了一些普及的文档后,很快就认识了不少业界的人,这些交际很大程度还影响到了我之后的职业生涯。

在07年加入阿里后,所做的工作其实和OSGi没有任何关系,自己甚至也觉得不会再和OSGi有任何关系了,但所谓的情结必须说就是深入骨髓的,到09年自己所负责的产品出现class不隔离导致的一些问题后,就立刻想着引入OSGi,这个决定可以说和情结有很大的关系,把自己最熟悉、最喜欢的一个东西放到商业级的产品中,这我想是很多情结最后最好的输出吧,当时为了给自己找到充分的理由,就把动态化也写为了需求的重点,class隔离+动态化,那绝对是OSGi的完美场景,于是整个团队在这件事上扑腾了好几个月,OSGi是引入了,动态化最后放弃了(实在太复杂,对于有状态的class要做到动态化实在太麻烦,而且在集群化的背景下其实意义不大),团队成员为了熟悉OSGi的开发模式花费了巨大的精力,并且以后加入团队的人也都受到不小的困扰,在那次折腾后,尽管看似情结输出了,但从此以后几乎所有来问我做插件化、class隔离等方案的选择时,我基本都会告诉他们不要用OSGi。

从OSGi情结这件事后,我就再也没有把情结和工作严格绑定了,情结能输出到工作最好,不能输出也OK。

在工作的历程中,也还看到其他很多类似的case,例如框架情结的同学,有些时候很容易做出决定是在自己所做的东西中要使用某框架,而也许公司内其实有类似的产品,并且有专职团队的维护和支持,说到这个必须说说以前经历的一个case是有一个同学对MongoDB非常有情结,于是在自己的一个产品中就引入了MongoDB,但其实自己对MongoDB的细节并不算非常清楚,结果后来运行过程中出问题了无法处理,而且其实后来review方案会发现在该场景中MySQL完全就可以满足;又例如语言情结的同学,有时候很容易做出决定是在自己所做的东西中使用某语言,而完全不顾及整个公司可能没太有这方面的人才,以后这东西还能不能维护得下去,说到这个可以说说火热的node.js,情况也类似,在运行过程中出现问题,没人能处理,只能临时Google等,搞得非常被动。

其实有技术情结不是坏事,反而多数是对技术有热情的人才会有技术情结吧,但技术情结是否要落到工作中,这个就必须深思熟虑了,工作其实是工程化的东西,工程化要考虑的因素非常的多,例如框架是否有专职团队支撑,未来的可维护性和持续发展性,甚至是业界的人才状况等都要考虑,所以很多时候语言的争论什么的其实意义不大,当然纯技术层面的讨论OK。

你会有什么技术情结呢,会不会有无论如何都得把情结输出到工作中的想法,或者你看到过什么现象,经历过什么故事,来回复说说看。

=============================
欢迎关注微信公众号:hellojavacases

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

公众号上发布的消息都存放在http://hellojava.info上。

探讨下DevOPS

技术界一直就是新名词不断的风格,DevOPS这个词话说出来也挺长时间了,一直以来对这个不算太明白,以为就是指OPS应该不仅仅做OPS的工作,而是应该同时承担起开发自己OPS工作的系统,注意指的是系统,而不是脚本,因为很多的OPS操作是一个流程式的多步骤组成,并且多集群,多系统的交互,这个时候用脚本去实现是会比较难的,而且还要处理诸多的异常等,系统是一个工程性的东西,不仅仅是功能的实现,还要考虑很多异常、稳定性等的问题,但最近的一些思考,让自己对DevOPS有了更多的看法。

OPS去承担起开发自己OPS工作的系统这个比较容易理解,最大的原因在于自己的痛其实只有自己最清楚,很多家公司估计都尝试过让一个专职的团队来开发OPS用的系统,结果就是专职的这个团队和OPS团队挺容易引发争执,然后系统也通常不能很好的解决问题,而一旦转变为OPS自己来做系统给自己用,那问题被解决的可能性会大幅提高,而且有不少公司确实也是OPS采用OnCall轮转的机制,Oncall的时候专心干OPS的活,不OnCall的同学则专心写系统解决自己之前OnCall的时候手工干的活,不过这种方式下比较容易碰到的一个问题可能是写出来的系统的质量不够理想,例如对于运维系统来说,在成功率的要求上会远比在线系统高,但在性能、并发这两点上会远比在线系统低。

除了上面这个点外,运维团队通常还很容易碰到的一个问题是研发交付的系统可运维性不太好,这种时候通常只能是纯操作方面的事运维先人肉顶着,但碰到一些故障的时候,如果系统可运维性比较差,会导致排查过程极度复杂,耗时长,而在有研发和运维这两个独立岗位的时候,这种现象很容易导致的结果就是运维在苦逼的处理一堆的这样的事情,研发呢反正也不是很能感受到这样的痛(因为一个研发可能就负责一两个系统的开发,但一个运维通常可能负责几十个甚至更多系统的运维工作),于是也不是很在乎,最终导致很容易出现的现象就是运维推着研发做很多可运维性的改造,无论是运维体系标准的建设,监控体系标准的建设等,但这个推动通常其实不会那么容易,最重要的原因我自己觉得主要是体感的问题。

所以我现在理解中的DevOPS,我觉得是消除OPS这个独立岗位,让研发和运维合并成同一岗位,研发系统的团队轮值安排OnCall,这样会让研发系统的同学深刻感受到系统设计不靠谱的时候给运维阶段带来的痛苦,从而把本来就应该在设计阶段考虑的可运维性考虑进去,同时也避免了两个团队带来的协调成本等,并且对于研发而言,由于“偷懒”的特性,很容易就会去打造系统来解决手工干的活,站在这样的角度,我觉得就很容易理解为什么叫DevOPS,而不是OPSDev。

大家也可以探讨下你所感受到的运维是怎么样,你觉得变成什么样是比较不错的。

=============================
欢迎关注微信公众号:hellojavacases

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

公众号上发布的消息都存放在http://hellojava.info上。

从一个故障说说Java的三个BlockingQueue

最近出了个故障,排查的时候耗费了很长的时间,回顾整个排查过程,经验主义在这里起了不好的作用,直接导致了整个故障排查的时间非常长,这个故障的根本原因在于BlockingQueue用的有问题,顺带展开说说Java中常用的几个BlockingQueue:ArrayBlockingQueue、LinkedBlockingQueue和SynchronousQueue。

当时故障的现象是应用处理请求的线程池满了,导致请求处理不了,于是dump线程,看线程都在做什么,结果发现线程都Block在写日志的地方,以前出现过很多次问题,去线程dump的时候看到也是一堆的block在写日志,但通常是别的原因引发的,所以这次也是按照这样的经验,认为肯定不会是写日志这个地方的问题,于是各种排查…折腾了N久后,回过头看发现持有那把日志锁的地方是自己人写的代码,那段代码在拿到了这个日志锁后,从线程堆栈上看,block在了ArrayBlockingQueue.put这个地方,于是翻看这段代码,结果发现这是个1024长度的BlockingQueue,那就意味着如果这个Queue被放了1024个对象的话,put就一定会被block住,而且其实翻代码的时候能看出写代码的同学是考虑到了BlockingQueue如果满了应该要处理的,代码里写着:

if (blockingQueue.remainingCapacity() < 1) { //todo } blockingQueue.put

这里两个悲催的问题,一是这个if判断完还是直接会走到put,而不是else,二是竟然关键的满了后的处理逻辑还在//todo...
另外我觉得这段代码还反应了同学对BlockingQueue的接口不太熟,要达到这个效果,不需要这样先去判断,更合适的做法是用blockingQueue.offer,返回false再做相应的异常处理。

BlockingQueue是在生产/消费者模式下经常会用到的数据结构,通常常用的主要会是ArrayBlockingQueue、LinkedBlockingQueue和SynchronousQueue。

ArrayBlockingQeue/LinkedBlockingQueue两者的最大不同主要在于存放Queue中对象方式,一个是数组,一个是链表,代码注释里也写到了两者的不同:
Linked queues typically have higher throughput than array-based queues but less predictable performance in most concurrent applications.

SynchronousQueue是一个非常特殊的BlockingQueue,它的模式是在offer的时候,如果没有另外一个线程正在take或poll的话,那么offer就会失败;在take的时候,如果没有另外的线程正好并发在offer,也会失败,这种特殊的模式非常适合用来做要求高响应并且线程出不固定的线程池的Queue。

对于在线业务场景而言,所有的并发,外部访问阻塞的地方的一个真理就是一定要有超时机制,我不知道见过多少次由于没有超时造成的在线业务的严重故障,在线业务最强调的是快速处理掉一次请求,所以fail fast是在线业务系统设计,代码编写中的最重要原则,按照这个原则上面的代码最起码明显犯的错误就是用put而不是带超时机制的offer,或者说如果是不重要的场景,完全就应该直接用offer,false了直接抛异常或记录下异常即可。

对于BlockingQueue这种场景呢,除了超时机制外,还有一个是队列长度一定要做限制,否则默认的是Integer.MAX_VALUE,万一代码出点bug的话,内存就被玩挂了。

说到BlockingQueue,就还是要提下BlockingQueue被用的最多的地方:线程池,Java的ThreadPoolExecutor中有个参数是BlockingQueue,如果这个地方用的是ArrayBlockingQueue或LinkedBlockingQueue,而线程池的coreSize和poolSize不一样的话,在coreSize线程满了后,这个时候线程池首先会做的是offer到BlockingQueue,成功的话就结束,这种场景同样不符合在线业务的需求,在线业务更希望的是快速处理,而不是先排队,而且其实在线业务最好是不要让请求堆在排队队列里,在线业务这样做很容易引发雪崩,超出处理能力范围直接拒绝抛错是相对比较好的做法,至于在前面页面上排队什么这个是可以的,那是另外一种限流机制。

所以说在写高并发、分布式的代码时,除了系统设计外,代码细节的功力是非常非常重要的。

=============================
欢迎关注微信公众号:hellojavacases

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

公众号上发布的消息都存放在http://hellojava.info上。

我在系统设计上犯过的14个错

在上篇《架构师画像》的文章中提到了自己在系统设计上犯过的一些错,觉得还挺有意义的,这篇文章就来回顾下自己近八年来所做的一些系统设计,看看犯的一些比较大的血淋淋的错误(很多都是推倒重来),这八年来主要做了三个基础技术产品,三个横跨三年的大的技术项目(其中有两个还在进行中),发现大的错误基本集中在前面几年,从这个点看起来能比较自豪的说在最近的几年在系统设计的掌控上确实比以前成熟了很多。

第1个错
在设计服务框架时,我期望服务框架对使用者完全不侵入,于是做了一个在外部放一个.xml文件来描述spring里的哪些bean发布为服务的设计,这个版本发布后,第一个小白鼠的用户勉强在用,但觉得用的很别扭,不过还是忍着用下去了,到了发布的时候,发现出现了两个问题,一是这个xml文件研发也不知道放哪好,所以到了发布的时候都不知道去哪拿这个xml文件。
这个设计的关键错误就在于在设计时没考虑过这个设计方式对研发阶段、运维阶段的影响,后来纠正这个错误的方法是去掉了这个xml文件,改为写了一个Spring FactoryBean,用户在spring的bean配置文件中配置下就可以。
因此对于一个架构师来说,设计时在全面性上要充分考虑。

第2个错
服务框架在核心应用上线时,出现了前端web应用负载高,处理线程数不够用的现象,当时处理这个故障的方式是回滚了服务框架的上线,这个故障排查了比较长的时间后,查到的原因是服务框架用的JBoss Remoting在通信时默认时间是60s,导致一些处理速度慢的请求占据了前端web应用的处理线程池。
上面这里故障的原因简单来说是分布式调用中超时时间太长的问题,但更深层次来思考,问题是犯在了设计服务框架时的技术选型,在选择JBoss-Remoting时没有充分的掌握它的运行细节,这个设计的错误导致的是后来决定放弃JBoss-Remoting,改为基于Mina重写了服务框架的通信部分,这里造成了服务框架的可用版本发布推迟了两个多月。
因此对于一个架构师来说,在技术选型上对技术细节是要有很强的掌控力的。

第3个错
在服务框架大概演进到第4个版本时,通信协议上需要做一些改造,突然发现一个问题是以前的通信协议上是没有版本号的,于是悲催的只能在代码上做一个很龌蹉的处理来判断是新版本还是老版本。
这个设计的错误非常明显,这个其实只要在最早设计通信协议时参考下现有的很多的通信协议就可以避免了,因此这个错误纠正也非常简单,就是参考一些经典的协议重新设计了下。
因此对于一个架构师来说,知识面的广是非常重要的,或者是在设计时对未来有一定的考虑也是非常重要的。

说到协议,就顺带说下,当时在设计通信协议和选择序列化/反序列化上没充分考虑到将来多语言的问题,导致了后来在多语言场景非常的被动,这也是由于设计时前瞻性的缺失,所谓的前瞻性不是说一定要一开始就把未来可能会出现的问题就解掉,而是应该留下不需要整个改造就可以解掉的方法,这点对于架构师来说也是非常重要的。

第4个错
在服务框架切换为Mina的版本上线后,发布服务的应用重启时出现一个问题,就是发现重启后集群中的机器负载严重不均,排查发现是由于这个版本采用是服务的调用方会通过硬件负载均衡去建立到服务发布方的连接,而且是单个的长连接,由于是通过硬件负载均衡建连,意味着服务调用方其实看到的都是同一个地址,这也就导致了当服务发布方重启时,服务调用方重连就会集中的连到存活的机器上,连接还是长连,因此就导致了负载的不均衡现象。
这个设计的错误主要在于没有考虑生产环境中走硬件负载均衡后,这种单个长连接方式带来的问题,这个错误呢还真不太好纠正,当时临时用的一个方法是服务调用方的连接每发送了1w个请求后,就把连接自动断开重建,最终的解决方法是去掉了负载均衡设备这个中间点。
因此对于一个架构师来说,设计时的全面性要非常的好,我现在一般更多采用的方式是推演上线后的状况,一般来说在脑海里过一遍会比较容易考虑到这些问题。

第5个错
服务框架在做了一年多以后,某个版本中出现了一个严重bug,然后我们就希望能通知到用了这个版本的应用紧急升级,在这个时候悲催的发现一个问题是我们压根就不知道生产环境中哪些应用和机器部署了这个版本,当时只好用一个临时的扫全网机器的方法来解决。
这个问题后来纠正的方法是在服务发布和调用者在连接我们的一个点时,顺带把用的服务框架的版本号带上,于是就可以很简单的知道全网的服务框架目前在运行的版本号了。
因此对于一个架构师来说,设计时的全面性是非常重要的,推演能起到很大的帮助作用。

第6个错
服务框架这种基础类型的产品,在发布时会碰到个很大的问题,就是需要通知到使用者去发布,导致了整个发布周期会相当的长,当时做了一个决定,投入资源去实现完全动态化的发布,就是不需要重启,等到做的时候才发现这完全就是个超级大坑,最终这件事在投入两个人做了接近半年后,才终于决定放弃,而且最终来看其实升级的问题也没那么大。
这个问题最大的错误在于对细节把握不力,而且决策太慢。
因此对于一个架构师来说,技术细节的掌控非常重要,同时决策力也是非常重要的。

第7个错
服务发布方经常会碰到一个问题,就是一个服务里的某些方法是比较耗资源的,另外的一些可能是不太耗资源,但对业务非常重要的方法,有些场景下会出现由于耗资源的方法被请求的多了些导致不太耗资源的方法受影响,这种场景下如果要去拆成多个服务,会导致开发阶段还是挺痛苦的,因此服务框架这边决定提供一个按方法做七层路由的功能,服务的发布方可以在一个地方编写一个规则文件,这个规则文件允许按照方法将生产环境的机器划分为不同组,这样当服务调用方调用时就可以做到不同方法调用到不同的机器。
这个功能对有些场景来说用的很爽,但随着时间的演进和人员的更换,能维护那个文件的人越来越少了,也成为了问题。
这个功能到现在为止我自己其实觉得也是一直处于争议中,我也不知道到底是好还是不好…
因此对于一个架构师来说,设计时的全面性是非常重要的。

第8个错
服务框架在用的越来越广后,碰到了一个比较突出的问题,服务框架依赖的jar版本和应用依赖的jar版本冲突,服务框架作为一个通用技术产品,基本上没办法为了一个应用改变服务框架自己依赖的jar版本,这个问题到底怎么去解,当时思考了比较久。
可能是由于我以前OSGi这块背景的原因,在设计上我做了一个决定,引入OSGi,将服务框架的一堆jar处于一个独立的classloader,和应用本身的分开,这样就可以避免掉jar冲突的问题,在我做了引入OSGi这个决定后,团队的1个资深的同学就去做了,结果是折腾了近两个月整个匹配OSGi的maven开发环境都没完全搭好,后来我自己决定进去搞这件事,即使是我对OSGi比较熟,也折腾了差不多1个多月才把整个开发的环境,工程的结构,以及之前的代码基本迁移为OSGi结构,这件事当时折腾好上线后,效果看起来是不错的,达到了预期。
但这件事后来随着加入服务框架的新的研发人员越来越多,发现多数的新人都在学习OSGi模式的开发这件事上投入了不少的时间,就是比较难适应,所以后来有其他业务问是不是要引入OSGi的时候,我基本都会建议不要引入,主要的原因是OSGi模式对大家熟悉的开发模式、排查问题的冲击,除非是明确需要classloader隔离、动态化这两个点。
让我重新做一个决策的话,我会去掉对OSGi的引入,自己做一个简单的classloader隔离策略来解决jar版本冲突的问题,保持大家都很熟悉的开发模式。
因此对于一个架构师来说,设计时的全面性是非常重要的。

第9个错
服务框架在用的非常广了后,团队经常会被一个问题困扰和折腾,就是业务经常会碰到调用服务出错或超时的现象,这种情况通常会让服务框架这边的研发来帮助排查,这个现象之所以查起来会比较复杂,是因为服务调用通常是多层的关系,并不是简单的A–>B的问题,很多时候都会出现A–>B–>C–>D或者更多层的调用,超时或者出错都有可能是在其中某个环节,因此排查起来非常麻烦。
在这个问题越来越麻烦后,这个时候才想起在09年左右团队里有同学看过G家的一篇叫dapper的论文,并且做了一个类似的东西,只是当时上线后我们一直想不明白这东西拿来做什么,到了排查问题这个暴露的越来越严重后,终于逐渐想起这东西貌似可以对排查问题会产生很大的帮助。
到了这个阶段才开始做这件事后,碰到的主要不是技术问题,而是怎么把新版本升级上去的问题,这个折腾了挺长时间,然后上线后又发现了一个新的问题是,即使服务框架具备了Trace能力,但服务里又会调外部的例如数据库、缓存等,那些地方如果有问题也会看不到,排查起来还是麻烦,于是这件事要真正展现效果就必须让Trace完全贯穿所有系统,为了做成这件事,N个团队付出了好几年的代价。
因此对于一个架构师来说,设计时的全面性、前瞻性非常重要,例如Trace这个的重要性,如果在最初就考虑到,那么在一开始就可以留好口子埋好伏笔,后面再要做完整就不会太复杂。

第10个错
服务的发布方有些时候会碰到一个现象是,服务还没完全ready,就被调用了;还有第二个现象是服务发布方出现问题时,要保留现场排查问题,但服务又一直在被调用,这种情况下就没有办法很好的完全保留现场来慢慢排查问题了。
这两个现象会出现的原因是服务框架的设计是通过启动后和某个中心建立连接,心跳成功后其他调用方就可以调用到,心跳失败后就不会被调到,这样看起来很自动化,但事实上会导致的另外一个问题是外部控制上下线这件事的能力就很弱。
这个设计的错误主要还是在设计时考虑的不够全面。
因此对于一个架构师来说,设计时的全面性非常重要。

第11个错
在某年我和几个小伙伴决定改变当时用xen的模式,换成用一种轻量级的“虚拟机”方式来做,从而提升单机跑的应用数量的密度,在做这件事时,我们决定自己做一个轻量级的类虚拟机的方案,当时决定的做法是在一个机器上直接跑进程,然后碰到一堆的问题,例如从运维体系上来讲,希望ssh到“机器”、独立的ip、看到自己的系统指标等等,为了解决这些问题,用了N多的黑科技,搞得很悲催,更悲催的是当时觉得这个问题不多,于是用一些机器跑了这个模式,结果最后发现这里面要黑科技解决的问题实在太多了,后来突然有个小伙伴提出我们试用lxc吧,才发现我们之前用黑科技解的很多问题都没了,哎,然后就是决定切换到这个模式,结果就是线上的那堆机器重来。
这个设计的主要错误在于知识面不够广,导致做了个不正确的决定,而且推倒重来。
因此对于一个架构师来说,知识面的广非常重要,在技术选型这点上非常明显。

第12个错
还是上面这个技术产品,这个东西有一个需求是磁盘空间的限额,并且要支持磁盘空间一定程度的超卖,当时的做法是用image的方式来占磁盘空间限额,这个方式跑了一段时间觉得没什么问题,于是就更大程度的铺开了,但铺开跑了一段时间后,出现了一个问题,就是经常出现物理机磁盘空间不足的报警,而且删掉了lxc容器里的文件也还是不行,因为image方式只要占用了就会一直占着这个大小,只会扩大不会缩小。
当时对这个问题极度的头疼,只能是删掉文件后,重建image,但这个会有个要求是物理机上有足够的空间,即使有足够的空间,这个操作也是很折腾人的,因为得先停掉容器,cp文件到新创建的容器,这个如果东西多的话,还是要耗掉一定时间的。
后来觉得这个模式实在是没法玩,于是寻找新的解决方法,来满足磁盘空间限额,允许超卖的这两需求,最后我们也是折腾了比较长一段时间后终于找到了更靠谱的解决方案。
这个设计的主要错误还是在选择技术方案时没考虑清楚,对细节掌握不够,考虑的面不够全,导致了后面为了换掉image这个方案,用了极大的代价,我印象中是一堆的人熬了多次通宵来解决。
因此对于一个架构师来说,知识面的广、对技术细节的掌控和设计的全面性都非常重要。

第13个错
仍然是上面的这个技术产品,在运行的过程中,突然碰到了一个虚拟机中线程数创建太多,导致其他的虚拟机也创建不了线程的现象(不是因为物理资源不够的问题),排查发现是由于尽管lxc支持各个容器里跑相同名字的账号,但相同名字的账号的uid是相同的,而max processes是限制在UID上的,所以当一个虚拟机创建的线程数超过时,就同样影响到了其他相同账号的容器。
这个问题我觉得一定程度也可以算是设计问题,设计的时候确实由于对细节掌握的不够,考虑的不全导致忽略了这个点。
因此对于一个架构师来说,对技术细节的掌控和设计的全面性都非常重要。

第14个错
在三年前做一个非常大的项目时,项目即将到上线时间时,突然发现一个问题是,有一个关键的点遗漏掉了,只好赶紧临时讨论方案决定怎么做,这个的改动动作是非常大的,于是项目的上线时间只能推迟,我记得那个时候紧急周末加班等搞这件事,最后带着比较高的风险上了。
这个问题主要原因是在做整体设计时遗漏掉了这个关键点的考虑,当时倒不是完全忽略了这个点,而是在技术细节上判断错误,导致以为不太要做改动。
因此对于一个架构师来说,对技术细节的掌控是非常重要的,这里要注意的是,其实不代表架构师自己要完全什么都很懂,但架构师应该清楚在某个点上靠谱的人是谁。

=============================
欢迎关注微信公众号:hellojavacases

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

公众号上发布的消息都存放在http://hellojava.info上。

深入JVM彻底剖析前面ygc越来越慢的case

阿里JVM团队的同学帮助从JVM层面继续深入的剖析了下前面那个ygc越来越慢的case,分析文章相当的赞,思路清晰,工具熟练,JVM代码熟练,请看这位同学(阿里JVM团队:寒泉子)写的文章,我转载到这。

Demo分析
虽然这个demo代码逻辑很简单,但是其实这是一个特殊的demo,并不简单,如果我们将XStream对象换成Object对象,会发现不存在这个问题,既然如此那有必要进去看看这个XStream的构造函数(请大家直接翻XStream的代码,这里就不贴了)。

这个构造函数还是很复杂的,里面会创建很多的对象,上面还有一些方法实现我就不贴了,总之都是在不断构建各种大大小小的对象,一个XStream对象构建出来的时候大概好像有12M的样子。

那到底是哪些对象会导致ygc不断增长呢,于是可能想到逐步替换上面这些逻辑,比如将最后一个构造函数里的那些逻辑都禁掉,然后我们再跑测试看看还会不会让ygc不断恶化,最终我们会发现,如果我们直接使用如下构造函数构造对象时,如果传入的classloader是AppClassLoader,那会发现这个问题不再出现了,代码如下:

[java]
public static void main(String[] args) throws Exception {
int i=0;
while (true) {
XStream xs = new XStream(null,null, new ClassLoaderReference(XStreamTest.class.getClassLoader()),null, new DefaultConverterLookup());
xs.toString();
xs=null;
}
}
[/java]

是不是觉得很神奇,由此可见,这个classloader至关重要。

不得不说的类加载器
这里着重要说的两个概念是初始类加载器和定义类加载器。举个栗子说吧,AClassLoader->BClassLoader->CClassLoader,表示AClassLoader在加载类的时候会委托BClassLoader类加载器来加载,BClassLoader加载类的时候会委托CClassLoader来加载,假如我们使用AClassLoader来加载X这个类,而X这个类最终是被CClassLoader来加载的,那么我们称CClassLoader为X类的定义类加载器,而AClassLoader和BClassLoader分别为X类的初始类加载器,JVM在加载某个类的时候对这三种类加载器都会记录,记录的数据结构是一个叫做SystemDictionary的hashtable,其key是根据ClassLoader对象和类名算出来的hash值,而value是真正的由定义类加载器加载的Klass对象,因为初始类加载器和定义类加载器是不同的classloader,因此算出来的hash值也是不同的,因此在SystemDictionary里会有多项值的value都是指向同一个Klass对象。

那么JVM为什么要分这两种类加载器呢,其实主要是为了快速找到已经加载的类,比如我们已经通过AClassLoader来触发了对X类的加载,当我们再次使用AClassLoader这个类加载器来加载X这个类的时候就不需要再委托给BClassLoader去找了,因为加载过的类在JVM里有这个类加载器的直接加载的记录,只需要直接返回对应的Klass对象即可。

Demo中的类加载器是否会加载类
我们的demo里发现构建了一个CompositeClassLoader的类加载器,那到底有没有用这个类加载器加载类呢,我们可以设置一个断点在CompositeClassLoader的loadClass方法上,可以看到会进入断点。
可见确实有类加载的动作,根据类加载委托机制,在这个Demo中我们能肯定类是交给AppClassLoader来加载的,这样一来CompositeClassLoader就变成了初始类加载器,而AppClassLoader会是定义类加载器,都会在SystemDictionary里存在,因此当我们不断new XStream的时候会不断new CompositeClassLoader对象,加载类的时候会不断往SystemDictionary里插入记录,从而使SystemDictionary越来越膨胀,那自然而然会想到如果GC过程不断去扫描这个SystemDictionary的话,那随着SystemDictionary不断膨胀,那么GC的效率也就越低,抱着验证下猜想的方式我们可以使用perf工具来看看,如果发现cpu占比排前的函数如果都是操作SystemDictionary的,那就基本验证了我们的说法,下面是perf工具的截图,基本证实了这一点。
perf

SystemDictionary为什么会影响GC过程
想象一下这么个情况,我们加载了一个类,然后构建了一个对象(这个对象在eden里构建)当一个属性设置到这个类里,如果gc发生的时候,这个对象是不是要被找出来标活才行,那么自然而然我们加载的类肯定是我们一项重要的gc root,这样SystemDictionary就成为了gc过程中的被扫描对象了,事实也是如此,可以看vm的具体代码(代码在:SharedHeap::process_strong_roots,感兴趣的同学可以直接翻这部分代码)。

看上面的SH_PS_SystemDictionary_oops_do task就知道了,这个就是对SystemDictionary进行扫描。

但是这里要说的是虽然有对SystemDictionary进行扫描,但是ygc的过程并不会对SystemDictionary进行处理,如果要对它进行处理需要开启类卸载的vm参数,CMS算法下,CMS GC和Full GC在开启CMSClassUnloadingEnabled的情况下是可能对类做卸载动作的,此时会对SystemDictionary进行清理,所以当我们在跑上面demo的时候,通过jmap -dump:live,format=b,file=heap.bin 命令执行完之后,ygc的时间瞬间降下来了,不过又会慢慢回去,这是因为jmap的这个命令会做一次gc,这个gc过程会对SystemDictionary进行清理。

修改VM代码验证
很遗憾hotspot目前没有对ygc的每个task做一个时间的统计,因此无法直接知道是不是SH_PS_SystemDictionary_oops_do这个task导致了ygc的时间变长,为了证明这个结论,我特地修改了一下代码,在上面的代码上加了一行:
GCTraceTime t(“SystemDictionary_OOPS_DO”,PrintGCDetails,true,NULL);
然后重新编译,跑我们的demo,测试结果如下:
2016-03-14T23:57:24.293+0800: [GC2016-03-14T23:57:24.294+0800: [ParNew2016-03-14T23:57:24.296+0800: [SystemDictionary_OOPS_DO, 0.0578430 secs]
: 81920K->3184K(92160K), 0.0889740 secs] 81920K->3184K(514048K), 0.0900970 secs] [Times: user=0.27 sys=0.00, real=0.09 secs]
2016-03-14T23:57:28.467+0800: [GC2016-03-14T23:57:28.468+0800: [ParNew2016-03-14T23:57:28.468+0800: [SystemDictionary_OOPS_DO, 0.0779210 secs]
: 85104K->5175K(92160K), 0.1071520 secs] 85104K->5175K(514048K), 0.1080490 secs] [Times: user=0.65 sys=0.00, real=0.11 secs]
2016-03-14T23:57:32.984+0800: [GC2016-03-14T23:57:32.984+0800: [ParNew2016-03-14T23:57:32.984+0800: [SystemDictionary_OOPS_DO, 0.1075680 secs]
: 87095K->8188K(92160K), 0.1434270 secs] 87095K->8188K(514048K), 0.1439870 secs] [Times: user=0.90 sys=0.01, real=0.14 secs]
2016-03-14T23:57:37.900+0800: [GC2016-03-14T23:57:37.900+0800: [ParNew2016-03-14T23:57:37.901+0800: [SystemDictionary_OOPS_DO, 0.1745390 secs]
: 90108K->7093K(92160K), 0.2876260 secs] 90108K->9992K(514048K), 0.2884150 secs] [Times: user=1.44 sys=0.02, real=0.29 secs]

我们会发现YGC的时间变长的时候,SystemDictionary_OOPS_DO的时间也会相应变长多少,因此验证了我们的说法。

有同学提到如果Demo代码改成不new XStream,而是直接new CompositeClassLoader或CustomClassLoader则不会出问题,按照上面的分析也很容易解释,就是因为如果直接new CustomClassLoader的话,并没触发loadClass这动作,而new XStream的话在构造器里就在loadClass。

有同学提到在JDK 8中跑这个case不会出现问题,原因是:jdk8在对SystemDictionary扫描时做了优化,增加了一层cache,大大减少了需要扫描的入口数。

=============================
欢迎关注微信公众号:hellojavacases

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

公众号上发布的消息都存放在http://hellojava.info上。

上篇文章中ygc越来越慢的case的原因解读

上篇文章中附加了一个最近碰到的奇怪的case,有位同学看到这个后周末时间折腾了下,把原因给分析出来了,分析过程很赞,非常感谢这位同学(阿里的一位同事,花名叫彦贝),在征求他的同意后,我把他写的整个问题的分析文章转载到这里。

    上分析工具VisualVM

在解决很多问题的时候,工具起的作用往往是巨大,很多时候通过工具分析,很快便能找到原因,但是这次并没有,下图是VisualVM观察到Heap上的GC图表。
visualvm

从图标中可以看出,Perm区空间基本水平,但是Old区空间成增长态势与YGCT时间增长的倍率基本一直。熟悉YGC的朋友都知道YGC主要分为标记和收回两个阶段,YGCT也是基于这2个阶段统计的。由于每次回收的空间大小差不多,所以怀疑是标记阶段使用的时间比较长,下面回顾一下JVM的垃圾标记方式。

    JVM垃圾回收的标记方法-枚举根节点

在Java语言里面,可作为GC Roots的节点主要在全局性的引用(例如常量或类静态属性)与执行上下文(例如栈帧中的本地变量表)中。如果要使用可达性分析来判断内存是否可回收的,那分析工作必须在一个能保障一致性的快照中进行——这里“一致性”的意思是整个分析期间整个执行系统看起来就像被冻结在某个时间点上,不可以出现分析过程中,对象引用关系还在不断变化的情况,这点不满足的话分析结果准确性就无法保证。这点也是导致GC进行时必须“Stop The World”的其中一个重要原因,即使是号称(几乎)不会发生停顿的CMS收集器中,枚举根节点时也是必须要停顿的。

由于目前的主流JVM使用的都是准确式GC,所以当执行系统停顿下来之后,并不需要一个不漏地检查完所有执行上下文和全局的引用位置,虚拟机应当是有办法直接得到哪些地方存放着对象引用。在HotSpot的实现中,是使用一组成为OopMap的数据结构来达到这个目的,在类加载完成的时候,HotSpot就把对象内什么偏移量上是什么类型的数据计算出来,在JIT编译过程中,也会在特定的位置记录下栈里和寄存器里哪些位置是引用。这样GC在扫描时就就可以直接得知这些信息了。
上面这段引用自《深入理解Java虚拟机》,用个图简单表示一下,当然图也是源于书中:
gcrootset

基于对GC Roots的怀疑,猜测Old区中存在越来越多的gc root节点,那什么样的对象是root节点呢?不懂的我赶紧google了一下。
gcroots

(不要看我红色圈出来了,第一次看到这几个嫌疑犯时我也拿不准是哪个)

为了进一步验证是Old区的GC Roots造成YGCT 增加的,我们来做一次full gc,干掉Old区。代码如下:

public class SlowYGC {
public static void main(String[] args) throws Exception {
int i= 0;
while (true) {
XStream xs = new XStream();
xs.toString();
xs = null;
if(i++ % 10000 == 0)
{
System.gc();
}
}
}
}

可以看出Full GC后 YGCT锐减到初始状态。那是Full GC到底回收了哪些对象?进入到下一步,增加VM参数。

增加VM参数
为了看到Full GC前后对象的回收情况,我们增加下面2个VM参数
-XX:+PrintClassHistogramBeforeFullGC -XX:+PrintClassHistogramAfterFullGC。
重新运行上面的代码,可以观察到下面的日志:
vmlog

上图左边是FGC前的对象情况,右边是FGC后的情况,结合我之前给出的GC Root候选人中的Monitor锁,相信你很快就找到20026个[Ljava.util.concurrent.ConcurrentHashMap$Segment对象几乎被全部回收了,ConcurrentHashMap中正是通过Segment来实现分段锁的。那什么逻辑会导致出现大量的Segment锁对象。继续看Full GC日志com.thoughtworks.xstream.core.util.CompositeClassLoader这个对象也差不多在FGC的时候全军覆没,所以怀疑是ClassLoader引起的锁竞争,下面在ClassLoader的源码中继续查找。

ClassLoader中的ConcurrentHashMap
classloader

这里有个拿锁的动作,跟进去看看呗。
parallelLockMap

为了验证走到这块逻辑下了一个断点。剩下的就是putIfAbsent方法(这里就不详细分析实现了)有兴趣的同学可以看看源码中CAS和tryLock的使用。
至此基本分析和定位出了YGCT原因,在去看看Xstream的构造函数。
xstream
可以看出每次new XstreamI()的同时会new一个新的ClassLoader,基本上证明了上述怀疑和猜测。

推导一下按照上述分析,应该是所有自定义的ClassLoader都会YGCT变长的时间问题,于是手写一个ClassLoader验证一下。Java代码如下:

public class TestClassLoader4YGCT {
public static void main(String[] args) throws Exception{
while(true)
{
Object obj = newObject();
obj.toString();
obj = null;
}
}

private static Object newObject() throws Exception
{
ClassLoader classLoader = new ClassLoader() {
@Override
public Class loadClass(String s) throws ClassNotFoundException {
try{
String fileName = s.substring(s.lastIndexOf(“.”) + 1)+ “.class”;
InputStream inputStream = getClass().getResourceAsStream(fileName);
if(inputStream == null){
return super.loadClass(s);
}
byte[] b = new byte[inputStream.available()];
inputStream.read(b);
return defineClass(s,b,0,b.length);
}catch (Exception e)
{
System.out.println(e);
return null;
}
}
};
Class obj = classLoader.loadClass(“jvmstudy.classload.TestClassLoader4YGCT”);
return obj.newInstance();
}
}
VM 参数-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xms512m -Xmx512m -Xmn100m -XX:+UseConcMarkSweepGC

GC日志
lastgclog

结论
当大量new自定义的ClassLoader来加载时,会产生大量ClassLoader对象以及parallelLockMap(ConcurrentHashMap)对象,导致产生大量的Segment分段锁对象,大大增加了GC Roots的数量,导致YGC中的标记时间变长。如果能直接看到YGCT的详细使用情况,这个结论会显得更加严谨。这只是我自己的一个推导,并不一定是正确答案。

=============================
欢迎关注微信公众号:hellojavacases

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

公众号上发布的消息都存放在http://hellojava.info上。

一个jstack/jmap等不能用的case

今天一个同学问我:”我排查问题时总是遇到,jmap -heap或-histo 不能用,是不是我们机器配置有啥问题哇? ” 分享下这个case的解决过程。

登上同学说的那台不能用的机器,执行jstack,报错:“get_thread_regs failed for a lwp”,这个问题以前碰到过,但忘了当时是什么原因了,执行其他的jmap -histo什么也卡着不动。

既然jstack没法弄,就pstack看看进程到底什么状况吧,于是pstack [pid]看,发现有一个线程的堆栈信息有点奇怪:
#0 0x00000038e720cd91 in sem_wait ()

对系统函数不太懂,但总觉得sem_wait这个有点奇怪,于是Google之,基本明白了这个是由于进程在等信号,这个时候通常会block住其他所有的线程,于是立刻ps看了下进程的状态,果然进程的状态变成了T,那上面碰到的所有现象都很容易解释了,于是执行:kill -CONT [pid],一切恢复正常。

继续查为什么进程状态会变成T,问问题的同学告诉了下我他在机器上执行过的一些命令,我看到其中一个很熟悉的命令:jmap -heap,看过我之前文章的同学估计会记得我很早以前分享过,在用cms gc的情况下,执行jmap -heap有些时候会导致进程变T,因此强烈建议别执行这个命令,如果想获取内存目前每个区域的使用状况,可通过jstat -gc或jstat -gccapacity来拿到。

到此为止,问题终于搞定,以后碰到jstack/jmap等不能用的时候,可以先看看进程的状态,因此还是那句话,执行任何一句命令都要清楚它带来的影响。

手头还有另外一个case,折腾了一个多星期了还是没太有头绪,case的现象是ygc越来越慢,但可以肯定不是由于cms gc碎片问题造成的,感兴趣的同学可以拿这个case去玩玩,如果能告诉我原因就更好了,:),执行下面的代码,启动参数可以为-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xms512m -Xmx512m -Xmn100m -XX:+UseConcMarkSweepGC:
[code]
import com.thoughtworks.xstream.XStream;

public class XStreamTest {

public static void main(String[] args) throws Exception {
while(true){
XStream xs = new XStream();
xs.toString();
xs = null;
}
}

}
[/code]

应该就可以看到ygc的速度从10+ms一直增长到100+ms之类的…

=============================
欢迎关注微信公众号:hellojavacases

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

公众号上发布的消息都存放在http://hellojava.info上。

架构师画像

架构师,这个title就和总监之类的title一样,已经彻底被用烂了,但在一个软件产品的生命周期中,架构师是实实在在的一个极度重要的角色,这篇文章就来讲讲我觉得的架构师的画像,到底具备什么素质的同学是贴合架构师形象的,同时欢迎大家回复下在你心目中NB的架构师的画像是怎么样的呢。

业务理解和抽象能力
架构师的第一职责是理解业务,并转换为可被研发理解的实现方案,因此业务理解能力是架构师的必备技能,通常来说一个资深的业务架构师,对业务会有非常深的认识和积累,一个极好的业务架构师应该能大概预判业务未来的发展趋势,以便在系统的可扩展性上留好一定的空间,所以也会很自然的出现有些业务架构师做着做着就干脆转为PD类型的角色。
抽象能力是通过对业务的理解转换为系统实现的模型,这显然也是重要的能力,抽象很多时候也承担了分解清楚多个团队的职责,分工清晰化。

NB的代码能力
之所以现在很多的架构师都会被认为是大忽悠,就是有一堆顶着架构师头衔,又不干活的人(甚至会出现对技术几乎不太懂的人),光说不干,再加上说的不靠谱的话自然很容易被认为是大忽悠,就我自己而言,我一直认为架构师有个非常重要的职责是编写整个系统中核心部分的代码,这个部分并一定是技术挑战最高的,但对整个系统的质量/成败与否是具备非常关键的控制作用的,所以架构师必须是从写核心代码的人中诞生出来的。
在一个跨多领域的大型系统中,架构师不太可能什么都擅长,不可能写各个部分的核心代码,这种时候架构师一定要知道怎么判断非自己知识领域的部分实现是否OK,以确保各部分组合在一起的时候是符合架构设计预期的,通常这种确保各部分组织在一起work的机制部分的代码应该由架构师自己操刀。

全面
全面是一个架构师展现出来的最关键素质,全面会体现在三点上:
1. 在面对业务问题上,架构师脑海里是否会浮现出多种技术方案,这点其实挺重要的,否则可能就会出现明明有一个简单成熟的方案,但由于不知道而做了其他复杂不成熟的方案,所以广阔的技术视野是架构师的必备,另外架构师不可能全部擅长,在自己不擅长的点上,需要知道找哪个专业的人是靠谱的,这点也非常重要;

2. 在做系统设计时是否考虑到了足够多的方方面面:
例如很多系统设计容易遗漏上线环节的细节,导致在上线时发现漏掉了什么考虑,临时解决或只能重来,记得有一年我做的一个设计没有考虑到上线阶段的一个细节,导致上线的时候发现由于网段的问题完全不work,并且没有临时解决方案,只好重来,系统设计不仅仅指导研发同学怎么写代码,也包括指导其他所有相关技术同学的工作;
又例如我2008年在做服务框架设计的时候,集群和集群之间通过硬件负载均衡设备来访问的,连接的方式是单个长连接,这个设计导致了运行过程中如果要发布被调用的服务方,很容易出现压力都集中在前面重启的机器上,这也是典型的整个链路没有考虑清楚造成的设计问题;
再例如2013年我在做一个比较大范围的系统改造的设计时,由于对其中一部分的软件了解的不够,判断错误,导致后来这个改造在进行过程中才发现有些需要改造的关键软件的设计做的太粗糙,最后上线进度差不多推迟了一个多月,而且那些后来补的设计都是紧急做的,风险非常高;
回顾自己设计过的软件,发现在这个点上犯的错可以讲好几天,看来我应该整理另外一篇文档《我在系统设计上犯过的xxx个错误》,里面有些其实靠一份好的系统设计模板也许就能避免掉,一份好的系统设计模板是可以帮助架构师思考全面些的。

3. 在做系统设计时是否考虑到了未来的一些发展,尽可能不要出现未来的一点变化就导致现在白干或要花大量力气来改造的现象,想当年做服务框架的时候,后来就发现由于当年做设计的时候没有考虑到将来服务调用trace的问题,导致了后来为了弥补这点花了巨大的力气(不是技术上,而是实施上)。

全面需要架构师有足够广的技术领域知识和足够多的经验积累,从全面这点就可以看到架构师的工作绝不是画几个框,连几根线那么简单。

对架构师全面这点的挑战,会随着系统的范围越大(一个系统的设计,和100个系统组成的大系统的设计挑战是完全不同的)而变得越难,无论是知识的广度、考虑的点的覆盖度、还是未来趋势,更复杂的情况甚至会出现架构的调整对应着组织结构的调整,这种也要考虑到,例如服务化这种大的架构改造,就意味着专职的专业领域服务团队的成立。

全局
全局观通常是指在系统设计时是否考虑到了对上下游的系统的影响,毕竟通常所设计的系统不是一个孤立的系统,如果没有足够好的全局观,有可能会导致自己的系统做完上线,其他上下游系统(尤其有些连上下游是谁,怎么用的都不知道的情况下)出现问题,这种案例同样不少。

权衡
权衡同样也是架构师极度重要的能力,或者也可以认为是决策能力,技术方案的拍板是一个架构师最重要的职责。
上面说的全面是架构师在思考时开的过程,而权衡就是收的过程,收的过程结束基本就意味着技术方案的确定,同时也确定了节奏,权衡在两点上会体现的特别突出:
1. 技术方案决策原则
通常一个问题都会有多种可解决的技术方案,怎么来决策就至关重要了,而决策通常又和全面相关,大的来说通常决策的原则就是性价比和可持续发展。
性价比简单来说是方案的实现成本,这个成本要包括非常多的方面,例如有些场景可能会是用硬件解决看起来是花钱,但最终折算成本是最划算的,很多系统设计在决策性价比时都过于随意,例如一个另外常见的场景就是建设一套新系统替代旧系统,这个时候可能完全没考虑旧系统的迁移代价甚至超过了改造旧系统的代价;
可持续发展简单来说就是所选择的技术方案在公司是否可持续,例如简单的案例是公司主体的研发人员都是php,却搞一个其他语言,且只有极少人懂的(当然,这还是要看性价比,如果搞一个其他语言带来的效益超过了语言/人才体系的更换成本),又例如引入一个开源产品,有无专业团队维护这都是要考虑的关键因素。

2. 优先级和节奏控制
经常我会问做系统设计的同学一个问题:对于这个业务场景而言,在系统设计上最需要把握的一个点是什么;这是一个关键问题,全面意味着考虑到了很多地方的问题,但通常业务需求实现都是有很强的时间要求的,因此在这个时候必须考虑清楚不同点的优先级,同时也包括技术方案在决策时也要做出取舍,有可能选了一个不是那么好的技术方案,但通过留下一些可改造的空间,为以后的重构做好铺垫,那就是很不错的,尤其技术同学有些时候比较容易陷入解决技术问题的场景去,但那个问题其实有可能不是现阶段最重要的。

其实优先级和节奏控制是我认为一个最NB的架构师的最佳体现,优先级意味着把握住了重点,可以确保在所设计的架构指导下业务实现不会出现大问题,节奏控制则意味着全面,为将来做好了铺垫。

=============================
欢迎关注微信公众号:hellojavacases

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

公众号上发布的消息都存放在http://hellojava.info上。

GC压垮了最后一根稻草

long time no see,:), 各种原因下导致了这么久没更新,准备再次捡起来了,先分享下最近碰到的一个case。

这个case的现象是:
整个集群fgc严重,导致无法为用户提供服务。

原因分析:
从现象来看,应该是个相当简单的类似内存泄露的问题,模式化的开始了OOM问题排查的过程。

拿到fgc严重时的heap dump进行分析,heap dump显示确实java heap基本被用满了,继续看Dominator tree,惊讶的发现排第一的才占了7%的内存;
切换到leakage的视图看,发现有一类型的类占据了超过40%的内存,用GC root跟是什么地方在引用这些类,看到的是很多的http线程在持有这些类的引用;
为什么这么多的http线程持有这些类的引用又不释放呢,需要看下这些线程都在做什么,于是切换到thread视图,发现这些http线程中除了一个在run,其他的都在等一把锁,run的那个线程持有了这把锁,继续看run的那个线程那行代码在做什么,发现那是个极为简单的动作,完全不可能运行很久,这样的现象说明是由于某些原因导致这个run的线程一直获取不到cpu资源;
翻查当时机器的状况,系统的状况是正常的,但Java应用一直在fgc,连续频繁的fgc导致了上面的那些线程压根就没有执行的机会,在这种情况下这个应用其实已经不可能恢复了。

上面分析了那么多,唯一能得到的结论就是应用本身没有内存泄露,但到底是什么原因触发了应用频繁fgc呢,继续翻查应用的gc log,发现有个现象是在频繁fgc之前cms gc的频率越来越近,并且每次回收后存活的空间占用的越来越大,造成这样的现象是应用的qps增高了太多,或者reponse time(rt)慢了很多造成的,查看应用的qps没什么变化,但应用的rt在cms gc频率变短前有些许的增长,这样基本能解释通:
应用rt增高,导致在cms gc执行的周期内存活的对象增多,于是cms gc频率开始缩短;
而cms gc频率缩短,又进一步导致了rt增高,开始形成了恶性循环。
因此说明这个应用在目前的机器数和qps下其实已经到达瓶颈了,稍微的rt或qps的波动都有可能导致整集群崩盘。

在这个结的情况下问题是没法解决的,要解决这个问题只能是提升应用的性能或扩容机器。

case带来的思考:
这种case其实挺折腾的,在以前讲线程池大小的帖子里也写过一次,就是线程池的最大值开的太大的话,看起来是能接更多的请求(如果cpu处理不是瓶颈的话),但不幸的是通常也会导致存活的对象增多,有可能触发gc,而gc的频繁介入很容易导致恶化的现象。

要预防这种case的另外一个更好的做法还是保持一定频率压测获得应用的单机qps能力,并做相应的限流,确保整体qps达到一定的水位后就扩容。

=============================
欢迎关注微信公众号:hellojavacases

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

公众号上发布的消息都存放在http://hellojava.info上。