我所关注的Java问题(Cont.)

上篇遗漏了两个关心的问题忘了写,继续补充下。

第一个是类隔离的问题,相信多数的Java开发同学都被类冲突的问题折磨过,maven为避免类冲突起到了一定的作用,但对于groupId、artifactId不一致,但又有同样full classname的类冲突,maven也无能为力,很不幸的是这种无节操的行为在Java应用中相当的多,即使是开源的项目中也一堆这种,因此类冲突带来的问题经常会是大家已知的一个不定时炸弹,但又不想去解决,等着看看Java 9中最重要的模块化的功能会实现的怎么样,话说模块化这功能推了真心够多年的。

第二个是Java应用对硬件资源消耗的分析工具,例如在目前的情况下,如果想知道一个Java应用的CPU消耗是哪些代码造成的,还真的是相当的折腾,perf和JVM的结合不是很好,本来perf应该是足够了,内存如果想知道主要是哪些代码造成的消耗,也同样非常折腾,尽管有Flight Recorder会起到一定的帮助作用,不过这块真心没看到官方有什么想法,估计只能靠自己。

关注的Java问题这篇没得到什么回应,或者换个问法,大家对Java有什么期望吗,你会期望Java支持一些什么特性,原因是什么。

Oracle官方的JDK 7又停止更新了,让大多数人估计都一定程度陷入了尴尬,尤其是对于用6的同学,稍微调查下大家现在用的JDK是什么版本呢?

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

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

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

我所关注的Java问题

Java作为一个发展了多年的语言,由于历史包袱等原因,自然会有不少问题,这里讲的是Oracle Hotspot(其他的JVM会有些不同),我最关注的主要是以下几个:

1. 对大内存的支持
内存容量发展越来越大,而自然Java应用也会越多的面对大内存的场景,目前Java在大内存的情况下,有两个主要的问题:
* GC问题,CMS GC最大的问题是碎片,碎片所导致的不可预知的Full GC的行为是非常可怕的,我们都有好几个应用开始要在每天低峰的时候强制执行full gc来避免碎片问题,G1GC也仍然是有碎片问题的…
* 排查问题,大内存的情况下dump、分析目前的Hotspot支持的都非常糟糕。

2. 启动瞬间慢的问题
Hotspot在刚启动时是解释模式,逐步才编译为native代码,因此一定会出现启动瞬间慢的现象,这个问题很容易导致有些访问量很高的应用在启动瞬间会出现非常多的请求失败的现象,尽管目前Hotspot也做了很多的努力,例如TieredCompilation等。

3. coroutine
很多的Java应用在处理请求时都会有大量的访问后端的行为,例如访问数据库、调用其他应用等,由于是线程模式,会导致在支撑很高的并发时会比较容易达到瓶颈,而coroutine对于类似这样的场景,会有不小的帮助。
而更进一步,对于分布式的Java应用来说,在一次请求中可能会有大量的并行的后端调用,这种时候如果是线程模式也不是很好做。

4. 序列化/反序列化
这个算比较特殊的一个点,在一次请求要访问非常多后端的情况下,序列化/反序列化通常会成为很重要的一个CPU的消耗点,而根据我们以往的排查我们能看到主要的原因还是在序列化/反序列化中从对象到流,以及从流到对象的过程,所以如果能在这里有突破的话,会对分布式的Java应用有很大的帮助。

5. 字符串append
之前我们在分析Java应用的内存消耗时,会看到StringBuilder/StringBuffer.append造成的char[]数组的扩充造成了主要的内存消耗,而其实这个如果有改进是可以大幅减少内存消耗的压力的(在我们的很多应用上,我们可以看到在很高并发量时GC占据的CPU还是不少的)。

这里还有一个牛人写的JVM implementation challenges的pdf,感兴趣的也可以看看。

你有什么特别关心的Java问题呢,也可以回复我说说看。

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

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

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

说说高大上的职业规划 for “码农”

职业规划,这个词说起来总感觉很虚,还有点高大上,不过对于几十年的职业生涯而言,职业规划确实还是挺重要的(尤其是工作了几年以后),说说我对“码农”的职业规划的看法(适合往管理方向发展的就不在这里说了),求轻拍。

“码农”主要分业务研发和基础研发,业务研发包括了各种编码实现业务的研发和架构师;基础研发包括了各种更偏基础技术产品的研发和架构师,例如内核、JVM等。

业务研发适合的发展方向我认为是业务PD、业务研发架构师和基础研发,业务研发要做好我觉得除了基本技术外,最重要的是商业敏感性,商业敏感性决定了在实现业务的时候能否为业务将来的发展模式做好铺垫,避免业务变化导致结构推翻,如果商业敏感性不错,可以考虑往业务PD或业务研发架构师的方向发展,更喜欢偏技术一点的话就选业务架构师,更喜欢偏纯业务的话就选业务PD,如果商业敏感性不是很够或没兴趣,并且对基础技术更感兴趣的话,我觉得更适合的发展方向会是朝基础研发方向发展。

基础研发适合的发展方向我认为是基础研发专家、平台架构师和业务研发。

如果优势更偏向于商业敏感性,适合的是转向业务研发方向发展。

基础研发专家和平台架构师这两个发展方向主要取决于个人对专和广的爱好,例如像JVM、内核就是非常专的方向,如果个人的兴趣和优势主要是做这类专的方向,我觉得整个职业规划是最好做的,就是在某个领域不断深挖就行,这类方向在大规模的公司中需求会比较强烈;另外一个方向是平台架构师,平台架构师适合喜欢在广度上发展的同学(或者没能力在专业领域做深),平台架构师最需要的是技术的广度、视野、眼光和平衡的能力,技术的广度是指技术的全栈掌握,软件不仅仅是编码实现,还得考虑实现后运行起来需要投入的成本、持续维护的能力,视野是指掌握业界在相应技术领域更前进一步的做法,眼光是指能够看到技术领域的发展方向,并且能够看到业务将来发展会带来的基础技术的挑战,平衡是指能根据现状(团队、目前的结构、时间)来权衡架构的发展节奏,这个是最难做到的。

所有的发展方向其实都不存在哪个能NB,哪个更low的问题,只有哪个更适合自己的问题,这主要取决于个人的优势和兴趣,另外还需要考虑的一个因素是长期的职业规划,例如以后是想创业做CEO,想加盟创业公司做CTO等,这也会很大程度影响到在一家公司的职位的选择。

最后例行的夹带点私货,:),我的团队很适合往基础研发专家、平台架构师方向发展的同学,在基础研发专家方向上提供了专业的性能、成本和可用性的三个方向,这三个方向的团队成员将专注于相应领域的技术,并且向全局业务负责;在平台架构师方向上我的团队所在的部门是一个全栈技术的部门,涉及到软件架构、服务器、网络、IDC等,对拓宽技术广度会有很大的帮助,这对成为一个平台架构师非常重要,另外我的团队也同样提供了专职做架构的职位,去考虑规模和业务多元化发展带来的架构挑战的问题,感兴趣的同学可以微信回复来联系我,非常期待!

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

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

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

服务化,你真的需要吗

服务化,SOA,绝对是一个火热了N年的词,再加上各大互联网公司在讲各自的技术架构演进时,基本都会提到服务化,这个诱惑的很多人都想对系统做服务化的改造,但你真的需要服务化吗?

所谓的服务化,是指根据业务的职责划分为多个系统,系统之间的交互以服务的方式进行,这样的好处看起来就是系统的职责变得非常清晰。

但其实呢,服务化并不仅仅是一个纯粹的技术改造,服务化就意味着业务是由多个系统构成,这个时候首先会产生的第一个核心问题是需要有相应的人员来维护,在服务化之前,通常来说模式都是一个系统,所有的开发共同维护一个系统,而服务化拆成多个系统后,就不可能所有的开发再共同维护了,因此做服务化之前,首先要做的第一点是组织结构的调整要对应的准备好,所以其实如果开发人员不多的话,显然是没必要做服务化的,否则连开发的人都不够分,Jeff Dean在有一次的topic上讲到服务化带来的一个好处:easier to have many engineering offices around the world.

另外,有很多想做服务化的原因是觉得服务化后职责清晰,开发效率更高,但事实上是,服务化后变成了多个系统,很多时候会出现为了实现一个需求,需要改多个系统(尽管服务化本来是希望能减少这种现象,但事实上很难做到),协调多个团队,而在一个系统的情况下,通常是每个开发都为整个系统负责,所以在实现需求时是可以一个开发搞定,这样的效率其实通常是更高的,所以其实我始终认为,服务化了以后整个开发效率是一定程度下降的,但好处是它可以支撑很大规模的开发团队。

所以从上面大家可以看到,服务化是在发展到一定情况下才需要做的,我自己觉得触发要做服务化的主要原因会是这三个:
1. 底层例如数据库连接到达上限
系统共用的底层资源在随着机器增加的越来越多时,一定会成为瓶颈,这种情况下服务化会带来帮助,当系统逻辑变简单的情况下,吞吐量自然也比较容易上升,这个时候使用底层资源的机器数自然可以大幅下降。

2. 开发人员规模庞大
当开发人员规模变大(100个左右)时,众多人共同维护一个系统会变得不可行,这个时候服务化可以产生巨大帮助,也会成为必须做的事情。

3. 业务多元化,共享的业务逻辑多
当业务朝多元化方向发展时,各个业务可能会有很多共享的业务逻辑出现,这个时候服务化会带来帮助,不过通常业务多元化也会自然带来开发人员规模庞大,不过这个方式在逐步发展中也会出现一些问题,但总体来说这种情况下服务化还是必须做的。

服务化改造还会带来其他一些问题,感兴趣的可以参见我以前写过的一篇《服务框架演变过程

如果没有上面的那些原因的话,我的建议都是能不做服务化的话还是尽量不要做。

所以一个架构师在做架构改造的决定时,最重要的是要考虑全面(各种平衡),很有可能架构改造并不仅仅是技术层面的事,并且需要判断架构改造发生的合适时间点。

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

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

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

一个Web应用访问偶尔慢的Case

在等待双11高峰来临之际,先来分享一个前几天排查的问题的case,这类case是目前我觉得排查起来挺折腾的。
ps: 大家都觉得我最近分享的cases在减少,一方面是很多重复的case,另外一方面是我这边有了一个专门排查问题的团队,很多的排查都由这个团队来承担了,之后我也会分享下这个团队的同学的文章,也欢迎有兴趣百分之百投入在问题排查、经验总结和更好的设计高可用系统的同学加入。

问题的现象是:
一个web应用的功能访问会间隙性的慢,但从server端来看指标一切正常。

排查过程:
首先看server端的状况,据用户反馈,包括我自己访问这系统的页面确实会间隙性的慢,重现倒不是太复杂,登录到server上,看历史的load、cpu等指标状况,一切都很正常。

查看gc log,也一切正常。

查看nginx的access log,可以看到响应时间都挺快的,没看到慢的现象。

到这步基本可以确定问题不在server端,对于web类型的应用慢的现象,问题不在server端的时候,对我来说就是排查最折腾的时候,因为前面的链路其实是比较长的,而且我自己其实也不太擅长。

因为访问时快时慢,问题又不在server端,首先怀疑是不是负载均衡上有问题,于是先拜托负载均衡的同学查有没有问题。

在chrome上刷页面,注意到的一个现象是慢的时候tab上的图标主要是在逆时针转,对chrome熟悉的人会知道这说明主要是在dns解析或建到服务器的连接速度慢。

继续用chrome的dev tool跟踪了下时间消耗,发现慢的时候主要消耗在了connection time上,于是更加怀疑是不是负载均衡上建连接的速度出现了时快时慢的现象。

请DNS的同事也帮忙介入了下,DNS的同事注意到一个问题是dns上挂载了两个vip,而其中的一个vip是disable状态。

由于其中一个vip是disable的,导致了dns解析到的地址有50%的概率会连不上,只能等到连失败的情况下才会换到没问题的那个地址,而在找到了没问题的那个地址后,会cache住,等到失效后才有可能再次出现上面的现象,所以表现出来就会是间隙性的慢。

到这一步原因终于是查清了,后来把disable的那个vip去掉,一切就正常了。

最近被好几个web应用访问间隙性慢的问题折腾的不行,一个web请求要进入到后端的server,整个过程相当的长,后端的话现在如果出现慢的现象我们基本可以用eagleeye(之前的文章中有介绍的)来排查,但web请求会比较复杂,如果涉及到网络问题就更加复杂了,我们现在正在计划做一个这样的全链条的工具,以便更好的排查这类问题,如果有谁知道有比较好用的工具,求推荐。

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

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

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

硅谷一个月之行

9月底的时候去了一趟硅谷,之前的几年也去过几次硅谷,这次的不同在于呆了1个月,比以前更加深度的接触了硅谷的方方面面,分享下自己的感触。

硅谷文化
这次在硅谷拜访了比较多的公司,也和不同公司的人聊了不少,比以前能更加多的感受到硅谷的文化。

接触下来,在公司这个层面,硅谷有很多极为专业的技术创新公司,公司运转的也还不错,里面的员工都非常的专业,多数都是在某个极为专业的领域做了N年的人,一大堆的博士,介绍技术创新的时候很多甚至会涉及到基础科学层面的东西,例如数学、物理、化学。

除了技术创新的公司外,还有更多业务创新的公司,目前美国最火的三家互联网方向的公司缩写为USA,分别是Uber、SnapChat、Airbnb,这三家的市值均超过百亿刀,他们都是业务玩法的创新,Uber、Airbnb都是典型的用碎片化的资源满足碎片化的需求,平台化、轻资产的公司(是不是有点熟的感觉),Uber对出租车行业产生的影响非常大,据说之前已经有出租车排长队在Uber公司楼下集体按喇叭抗议,更不用说现在Uber还扩展到了送快递、外卖等行业,Uber已被Google投资,目前估值180亿美刀;Airbnb除了提高闲置房间的利用率之外,还有一个更重要带来的好处是体验不同的人生风景,在和一些华人吃饭的时候,听到一个90后小孩说Airbnb甚至改变了他的人生观,他住过100多家Airbnb的房子,和不同房东的交流带给了他不一样的人生观,除了USA外(Snapchat不在硅谷),硅谷还有非常多市值不低的公司,像Dropbox、Pinterest等等,另外一个最火的公司说法是湾区四小龙:Uber、Dropbox、Square、Pinterest。

说到硅谷的这些新贵公司们,顺带说下另外一个有趣的现象,就是这些新贵的公司们都在逐渐从旧金山周边的卫星城市(例如以前比较集中的Palo Alto、Mountain View、Santa Clara、San Jose)这些地方搬到旧金山市内,据说主要的原因是年轻人更喜欢在市内工作;另外一个有趣的识别新贵公司的方法:看签到台,新贵公司基本都是一水的iPad自助,而且貌似都是同一套签到系统。

从一堆的技术、业务创新公司可以看出,硅谷在创新能力上还是非常强的,这个和文化、环境、政策有很大的关系,在硅谷基本上很多人会因为有了一个点上的新的想法就创办一家公司,硅谷的人才优势显然也是巨大的,这点对其保持创新的领先也非常的重要。

除了创新以外,硅谷的这些公司给我的另外一点很大的感触是全球化,体现在公司的人员、办公地点还有市场,这点说实话中国的公司还有很大的差距,中国的公司享受着中国的政策、人口红利,很多时候也许只做中国一个市场就已经可以超过硅谷的很多公司,但说实话是很难在硅谷得到尊重的,因为会被认为对世界的前进没起到什么作用,要做成一个全球化的公司,要求其实还是很高的,这点上中国的话估计华为体会是最深的。

不过貌似不少的华人都觉得在非华人的公司,华人的成长空间还是比较有限的,华人的高管确实不多,印度人现在成为高管的倒确实不少,这点对于中国公司进入美国招聘人才倒是有些帮助。

知乎上FB的同学对“大家最想去的IT互联网公司排名”问题的回答也可以看出一些硅谷文化,大家可以看看:http://www.zhihu.com/question/19629180/answer/32191175

硅谷生活
这次在硅谷生活了一个月,比以前每次呆个10天左右的情况确实更加适应了,觉得硅谷生活其实也挺不错的,说说这次在硅谷生活1个月在App、吃、住、行、购物、玩方面的一些感受和建议吧,:)

App
移动互联网时代,App的重要性就不用说了,好的App可以带来极大的便利性,在硅谷生活这段期间,我自己最依赖的是waze、yelp、priceline、skype和微信。

waze很多人估计还不一定听过,是Google收购的一个导航App,它的好用之处在于它是在线型的导航,因此可以通过收集用户的行车速度来更实时的判断路况(不像现在很多的导航软件的路况都是靠交管局信息,延时严重),同时还增加了很多趣味性的社交互动,例如车速慢的时候会跳出个窗口问“检测到车速慢,是否堵车”,大众投票的情况下准确性其实是有保障的,还会有例如前方x米处有警察,前方x米处有车停在路肩,甚至在1号公路上开的时候,还碰到过前方x米处有鹿穿行的提示,是一款非常有爱并且极为有帮助的导航软件(我有好几次都是因为这个绕开了巨堵的地段),无聊的副驾会得到很多欢乐的机会,另外我感觉貌似waze会把需要行进的路线的地图默认离线下载过来,在没有信号的时候也能正常导航,这个还是相当的重要,waze的流量消耗并不高,我每天都用,貌似最后一个月下来应该也没超过200M,因为Google已经收购了waze,所以之后路况等的信息就会共享给Google Map,不需要互动什么的话估计以后Google Map也就可以满足了。

waze是在线导航,所以免不了美国本地手机卡的问题,建议就是不要在淘宝上买,而是下飞机后再买,会便宜多了,而且买起来很方便,只要买prepaid的卡就ok了,甚至很多shopping mall都可以直接自助买,:)

yelp听过的人貌似会更多,可以认为就是美国版的“大众点评”,不过老外貌似是不太喜欢点评餐馆的,所以评论数据不太多,另外老外点评中餐馆的可信度不高,毕竟口味不同,:),但好处是至少可以快速知道附近有些什么餐馆以及大致的评价,所以还是会比较依赖。

priceline最近投资了携程好多次,我自己每次去美国基本都是用priceline来订酒店、租车,用priceline的bid方式的话基本都可以比市场价低个百分之几十订到酒店和租到车,所以我还是挺喜欢用的,:)

skype就很多人听过了,skype优在通话质量高,而且有大陆120通话的套餐,价格只需要9元,很不错。

微信,硅谷的华人圈貌似都用,再加上国内的联系,视频都用微信,还是很赞的。

其他像上面介绍到的uber、snapchat、airbnb,我只用过一次uber,主要是租车了,所以使用uber的需求不强烈,airbnb的话这次没来得及去体验下,旅游的话我觉得还是很值得用的,市内通行或不租车的话我觉得uber非常值得推荐。


以前去硅谷,我最受不了的就是吃,很难习惯,不过这次呆的时间长一些,貌似完全适应了,中西餐基本都ok,而且西餐的分餐制对我这样比较挑食的人其实挺爽,总是能挑到自己可以吃的东西,:)

中餐的话由于这次有硅谷各路的朋友带着去吃,吃到了不少好吃的中餐馆,甚至觉得比国内的中餐还好吃,一定程度上是因为原材料的原因,推荐几家中餐馆:
little sichuan(中文现在叫福恩园,在San Mateo Downtown)、Henry’s Hunan Restaurent(位于旧金山市内)、Chef Zhao(在Moutain View附近吧)、Cooking Papa(粤菜,有好几家,MountainView这家吃过,很赞)、Little Sheep Hotpot(小肥羊,我一直觉得比国内的好吃)、上海乔家栅(在Cupertino Village)、清真一条龙(在Milpitas Square),还有很多好吃的中餐馆,大家可以找硅谷的朋友们帮忙推荐,像听说的没去吃成的还有鲤鱼门、韶山冲。

西餐我就不知道了,对我来说就是肋排,:),其他的我说不上喜欢吃,肋排的话我觉得吃过的Willy’s、Outback都还不错,据说Bob’s的也很好吃,早餐的话我挺喜欢Jack in the box、Denny’s这些地方。


住的话这次折腾了好几个酒店,我自己不是很喜欢住Downtown之类的地方,所以我是觉得住在SF bay的几个城市挺好的,例如Brisbane、Burlingame、Foster,喜欢住市内的就另说,硅谷有挺多Suites类型的酒店,挺赞的。
旅游的话我觉得Airbnb去体验下是挺好的,值得推荐,不过这次忘了找Airbnb的朋友帮忙推荐几家。
在住上这次的感觉就是貌似硅谷的酒店比两年前贵了不少,连在priceline上都很难用低价bid到好一些的酒店。


在硅谷我觉得没有车还是很不方便的,吃饭、购物、玩什么的基本都得开车,不过还好就是租车并不复杂,而且价格也ok,租车的价格更多的是保险,说到这个,就必须说一定要记得带墨镜去,加州的阳光,那绝对不是盖的。

交通的话很发达,很多地方都是高速直达,并且都是免费的,在硅谷我都已经觉得20km什么的不算个啥,觉得很近,再加上硅谷这边开车基本都是极为遵守交规,我貌似只听到过三四次喇叭,而且好像有两次还是我自己引发的,和同事开玩笑说,在硅谷开车遵守交规,其实很多时候都是不好意思逼的,看着其他人那么礼让和遵守,自己都不好意思不遵守,另外我觉得老美开车还是相当快的,和中国的不同就是路上的车的行进速度都很快,所以即使车流量大,通行还是很不错的,不像中国,路上的车什么速度的都有,导致有些时候不变道根本没法开,由于老美开车速度都比较快,变道什么建议还是保持一定的提前量。

硅谷都是自助加油,中国的信用卡一般不能直接操作,需要找店员说然后才能自助加。

购物
硅谷地带有很多的shopping mall,比较出名的是几个outlet,例如Livermore Outlet,去这些地方一定要先去Guest Service拿个Coupon Book,可以享受折上折,在这些地方线下买东西会发现很多时候折上折后确实很便宜,amazon都没法比,所以感觉美国的电商貌似主要是靠便利性和商品的丰富性来形成优势,价格上我觉得倒是没什么优势,其他的shopping mall建议直接地图搜索shopping mall或shopping center,通常很轻松就能找到一堆,基本上要买的东西这些地方都可以买到的,实在不行的话还可以选择直接amazon或其他的一些电商网站直接买,然后寄到酒店就ok。
超市方面我觉得Target、Safeway之类的都挺好的,Costco的话适合批量买东西,价格便宜,而且需要有卡(不在美国居住的人貌似没法办的)。

顺带说下,很多东西硅谷并不贵,包括衣服,所以建议不用带太多的衣服什么过去,另外,美国好像都不怎么晒衣服,衣服都是直接烘干,洗衣服的话还是比较方便的,有些酒店会有自助洗衣机,如果没有的话也可以找找附近的clean & dry之类的店。

购物要注意的是回国时候的行李托运问题,要注意坐的航班允许托运的件数以及重量。


旧金山Downtown玩的地方貌似就是金门大桥、City Hall、Union Square、渔人码头、九曲花街、Twin Peak、金门公园等吧,金门大桥开到山上后可以继续往那边山下开,那下面有个沙滩我觉得挺不错的,还有彩色的石头,应该是叫Marin Headlands;Twin Peak适合晚上去,可以看整个旧金山的夜景。

周边不能错过的玩的地方是著名的加州1号公路,可以直接搜Pacific Beach,然后再导航到17Mile或Carmel都可以,这个中途千万别错过The Pigeon Point Light,这条公路被称为世界上最美的10条公路绝对不是吹的,沿途的风景非常的赞,如果有长的假期,例如15天以上,沿着这条路一直开到洛杉矶,确实赞,沿途可以欣赏到各式各样的风景,话说老美貌似还是挺热衷户外运动的,冲浪、hiking、骑车等等,一路上都能看到很多。

另外像著名的斯坦福大学、加州伯克利都是值得去去的,对于做IT的人来说,Google旁边的计算机历史博物馆我觉得也值得看看,对于VC的话,Sand Hill还是值得晃荡下,还有像Palo Alto的富人区也可以参观参观,那里有乔布斯的House,还有像Mark、Google的Page等也都在那有House。

总的来说,这次呆过后的感觉是硅谷在高科技领域的氛围确实很赞,信息、人才的流动都很顺畅,所以在这里确实很容易接触到更新的东西,更前沿的科技,生活方面嘛空气质量好(尽管很多老外和我说硅谷的空气质量已经不算好的),吃什么也都不错,比以前几次到硅谷觉得没法生活的感觉好了很多,已经觉得其实在硅谷生活一段时间也挺好的,不过长期呆会怎么样仍然不确定,:)

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

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

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

JavaOne 2014参会总结

4年前我参加了一次JavaOne,这是第二次参加,JavaOne的形式上和4年前完全一样,开会的地点、Rock Show、我无法适应的冷的午餐等也都一样。
JavaOne作为Java领域最高级别的会议(毕竟一众的Java大牛都在硅谷),总是会让人或多或少得到一些收获,尽管也会有一些水的Topic,我对一起参会的同事说,这种会议要么拓宽视野(就是听一些和自己工作可能完全无关的领域的状况),要么就是深入学习(JavaOne上不太缺深入的Topic)。

这次JavaOne我总计参加了20个Topic,分别来回顾下:
1. What’s up with modularity?
这是早上8:30–10:30的TUT性质的Topic,因此主要是现场用OSGi叫大家写模块化的代码,相对来说自己对这块还比较熟悉,唯一的感触是现在开发上貌似比以前成熟了一些。

2. Multitenant Java for High-Density Cloud Deployments
这个方向是自己比较感兴趣的,IBM做为这方面做的还不错的,确实值得听听,听下来最大的感触是:
* 这东西的实现机制非常诡异,我到现在都不太明白为什么IBM是采用多进程的方式来实现,我还想着如果是多进程的方式,那类似GC等问题就没了,另外像资源隔离等也就可以用类似cgroup来实现了;
* 这东西的成熟度我表示很质疑,例如要去解决全局的static、System.exit等问题,那会不会出现遗漏的点,这个其实有点象Linux Container的情况下要控制Container的权限是一样的,挺容易出现覆盖不全的现象,而这个的后果会比Container糟糕很多,因为搞不好是数据被篡改了什么的;
* 这东西的资源隔离上做的不成熟,现场的Demo来看cpu等控制的抖动非常严重。
所以我听完这个topic的唯一感觉就是,这个方向估计有点悬;

3. HTTP 2.0 comes to Java: What Servlet 4.0 Means to You
这个印象不怎么深了,总的来说就是Servlet 4.0会增加一些HTTP 2.0特性的接口,例如服务端的推送等;

4. ARM: Over 10 Billion Serverd
这场就是我说的希望拓宽视野的Topic,听这场的人非常少,连讲的同学都开玩笑说:果然是JavaOne,:)
这场听到的就是原来Java跑在ARM上是没问题的,但性能等很多方面差距还不小,例如64 bit暂时是不支持的,性能上Java的内存模型相关的指令优化ARM上是没有的。
听下来的感觉就是Java Server端要跑在ARM上还有很长的路要走。

5. Java Performance Is a Social Activity
这场真心没什么印象了,貌似主要还是强调Performance是要多人合作的。

6. Java Performance: Hardware, Structures, and Algorithms
这场是大牛讲的,topic的重点是Java Performance和硬件、数据结构等的关系,我印象最深的就是PPT上的工具截图,看起来是个非常NB的工具,可以显示到每行代码对CPU的消耗等,如果有同学知道是什么工具,麻烦告诉下。
另外大牛说很多Java应用对cpu cache使用的不够好,导致了performance不好,这个点话说之前真没太关注过,看来之后要试验下这个方向。
我和一起参会的同事说,这个Topic的重点是吐槽Java开发对硬件了解的太少,:)

7. Preventing Errors Before They Happen
也是一个TUT,主要是教大家用Type Checker来做编译期就把一些问题搞定的方法,例如参数是否null之类的。

8. where is my memory?
这个和上一个topic是同一个时间点,我稍微听了下上个topic就跑来听这个了,也是一个TUT,例如教大家怎么用jmap dump内存,怎么用MAT去分析,说实话,这个如果是阿里的同学讲我觉得可以讲的更全面,因为我们几乎碰过所有的Java Memory问题。

9. Java Concurrency Under The Hood
这个Topic超出了我的预期,必须给最高评价,按照大家比较一直的感觉是,JavaOne的topic不现场show或写代码,那压根都不好意思登场,这个Topic更狠,现场带着大家看JVM源码,来理解voliate Java是怎么实现的,这个太赞了,至少可以学习到一个如果从bytecode引导到JVM源码的方法(授人以鱼不如授人以渔),这种topic就必须现场听了(不过JavaOne很多都是现场写代码什么,所以很多PPT上都看不出什么)。
另外现场的一次举手中发现老外用Java 7的比例还真不低。

10. Java 8 Concurrency and Collections: what’s New
印象不算很深,因为几点改进之前也有一些了解。

11. Put a Firewall in Your JVM: Securing Java Applications
也是一个用于拓宽视野的topic,成功的做到了,至少它的做法让我觉得比较新鲜,我第一次看到直接在运行时来判断是否安全的做法,例如sql注入,它会判断运行的sql是否安全,如果不安全直接就屏蔽了,这种做法的好处是应用层面不需要改,直接底层就控制住了,例如现场还演示了如何修复struts bug,也是不需要修改struts代码。
这是一个商用的软件,觉得会有一些市场(例如现场就是一个银行的客户一起讲这个topic),毕竟要让写Java的同学都清楚怎么写安全的代码的难度还是不小的,尽管这种的做法应该会影响一些性能。

12. Is Your Code Parallel-Ready?
很多人吐槽这次JavaOne里关于Java 8 Streaming的topic太多了,确实,这也是其中一个,这个改进固然好,不过用那么多topic来讲就没必要了吧,对Streaming了解不多的同学可以去google看看。

13. Continuous Delivery and Zero Downtime
印象最深的就是有一页PPT上写着:No Deploy with snapshots,这个应该戳中了很多人的痛点吧,我们出现过多次因为Snapshot造成的故障…
其他的印象不算深…

14. Principles of Evolutionary Architecture
印象不深,我还是喜欢听show code的topic,:),这种原则性的听起来感觉不强烈,而且她里面讲到的例如make a decision as later as u can,这句其实我不是很赞同,在一个大规模的系统里,很多时候是需要有一些前瞻动作的。

15. Debugging and Profiling Robots with James Gosling
这个topic,大部分人显然是冲着Gosling去的,topic内容就是现场演示用JAVA控制的pi、飞行器等,Gosling的话是做了用java控制的在海上漂的小船之类的,这个topic最搞的是到问题阶段的时候,N多人问Gosling做了这个了是不是可以改行做fishman了,:)
topic一结束,N多人就拿着相机在拍Gosling…

16. Java in the Cloud: The Good Parts
这貌似是唯一的一个Google讲的Topic,印象深的就是Google显然主推docker,另外就是现场演示的cloud debugger好NB,在页面上设置一个断点,刷新页面,然后会跳入这个断点,这个真的太有需求了…

17. Understanding Latency and Response Time
这个topic最重要的是告诉大家不仅仅要看平均响应时间,还得看响应时间的分布,我们在这件事上是已经吃过亏的,平均响应时间很多时候抹掉了太多的问题,这个topic的PPT强烈推荐大家看看。

18. With GC Solved, what else makes a JVM pause?
这场我到的时候已经快结束了,不过我简单听下能感觉到这个topic还是很值得学习的,不过因为不属于show or write code的,所以可以download ppt来学习,这个topic讲了下除了GC会导致应用暂停外,还有哪些也会,其实知道这个是很重要的,例如jmap -histo:live也会,如果不知道有可能在生产环境随意执行,就会直接导致故障。

19. What’s cool in SAP JVM?
听这个topic的人非常的少,可能只有10个人,对我来说拓宽视野更重要,所以就去听了,至少现场演示的SAP JVM的allocation objects那个功能真心很需要,这个对性能优化等会有很大的帮助。

20. Virtualization-Aware Java
这是IBM的topic,一个小时的topic只讲了半个小时,真心没什么收获,重点强烈的就是JVM层面如何感知在什么虚拟化环境下,应该做什么相应的动作,这个我们采用的方法都是在内核层直接处理掉,无需JVM层面来知晓。

总的下来,我对JavaOne的评价是值得参加的,毕竟对视野的开阔、想深入了解的技术部分都会有一定的帮助,有些甚至能在参会后就形成一些Actions,这就足以了,现场Azul、Oracle的Topic质量都还不错,IBM的真心不咋样,不过话说我觉得阿里如果去讲讲Java支撑大型网站的架构,阿里碰到的一些Java问题的话,应该会更加吸引人,:)

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

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

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

内部的一次编程比赛

中间件团队举办了一次内部的编程比赛,个人觉得还是挺有意思的,把题目分享给大家,感兴趣的同学可以自己写着玩玩,之后也会把比赛最后成绩NB的人的优化思路分享给大家。

题目叫码农来搬砖,题目的要求为:
1. 实现一个客户端和一个服务器端,客户端把服务器端的一个1G的文件搬到客户端,文件中的每行字符串为一块砖头,字符串由随机的ascii32-127的字符组成,每行的长度为随机的1-200字节;
2. 服务端必须是单进程并且只能监听一个端口;
3. 客户端每个发起获取砖头的请求“线程“必须是一问一答,类似这样:
砖头 result = client.getZhuanTou();
4. 服务端收到请求后,必须是按顺序获取下一块砖头,类似这样:
砖头 next = server.getNext();
不允许批量处理请求,也不允许服务端处理请求的”线程“批量返回砖头,服务端处理请求的”线程“每次只能处理一个请求,并返回一块砖头;
5. 服务端或客户端需要对砖头进行处理,处理方式为去掉行中间的三分之一字符(从size/3字符开始去掉size/3个字符,除法向下取整)后将剩余部分以倒序的方式传输 例如 123456789 => 123789 => 987321,每块砖头需要标上序号,例如上面的123456789是第5行,那么最后的砖头结果应该为:5987321;
6. 客户端需要顺序的输出最终处理过的砖头内容到一个文件中,此文件中的砖头的顺序要和服务端的原始文件完全一致,文件不需要写透磁盘(例如java里就是可以不强制调sync);
7. 不允许采用内核层面的patch;
8. 不建议采用通信框架,例如netty之类的这种;
9. 不限语言、通信协议和连接数。

比赛的运行方式:
1. 服务端启动5s后启动客户端,客户端启动就开始计时,一直到客户端搬完所有砖头并退出计算为耗时时间;
2. 每次启动前清除pagecache。

内部最终有很多的同学参加了这次比赛,最终跑出的结果完全超出了我的想象,大家的优化都非常棒,让我学习到了很多。

我个人对这次比赛的意义的定位是普及通信领域的技术知识,并让大家玩的开心,这次比赛时间非常紧张,有不少同学为此放弃了中秋休假,我相信这些同学不是为了奖品,而纯粹是觉得玩的开心,我自己认为这是典型的程序员品质,:)

我几年前曾经想过做一个编程pk类的网站,上面有各种题目,然后大家只需要上传代码就会自动告诉结果,并更新是否闯入前10,后来由于各种原因这个网站没搞起来,后面看来还是要想办法搞起这个网站,喜欢玩这类的同学还是挺多的。

如果想自己玩这道题目但对题目意思还不是很确定的,可以直接回复下,我来解答,:)

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

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

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

又一个勉强算是解决的Case

最近真心陷入了怪圈,近期处理的cases要么是没解决,要么就是稀里糊涂的解决掉,这周又碰到了一个这样的case,尽管目前是解决了,但其实背后的原因仍然不清楚,给大家分享下先,是一个关于Young GC越来越慢的Case。

应用的现象是启动的那段时间每次Young GC耗时大概是10-20ms,运行几个小时后,Young GC的耗时就会逐步增长到200+ms(注意,是逐步增长,不是突然增长到这么大),继续运行的话,甚至会逐步增长到1s以上,但每次Young GC存活的对象和刚启动的那段时间其实没什么变化。

之前也碰到过几次Young GC变慢的现象,原因是:
1. CMS GC的碎片问题;
2. 用到了Swap。

于是按照这两个思路去排查,看应用的启动参数,应用确实是采用的CMS GC,于是我就强制触发了下Full GC,结果发现还是一样,没什么变化,说明不是碎片问题造成的。

接着查是不是用到了Swap,free -m可以看到swap也没用过,这个时候我只好怀疑是不是内存条出什么问题了,请硬件的同事帮忙check了下内存条是ok的。

到了这步,又悲催了,超出了自己的经验范围,于是想着要么换一个GC方式试试,就把CMS GC换成了ParallelOldGC,结果还是一样。

到这个阶段已经彻底没哲了,开始瞎折腾,就在瞎折腾的那段时间突然发现了一个现象,就是permgen涨的很快,当然,fgc的时候也会回收掉,于是就想着先用btrace挂上看看为什么permgen涨的快。

可是这个应用是用的jdk 7,挂上btrace跟踪后直接crash了…只好按照这个思路去问应用的同学,按以往经验,permgen涨的快通常都是因为错误使用groovy,于是直接问是不是用到了groovy,答复是用到了,不过用的方法是jdk 7 invokedynamic的方式去执行的groovy脚本,而在这种情况下执行的方式其实是把groovy脚本编译成class来执行的,所以理论上不太可能出现重复装载class,但btrace脚本又挂不上,就很难去排查了。

这个时候应用的同学告诉了一个有用的信息是,这个应用最近从groovy 2.1.x升级到了2.3.x,猜想莫非是升级造成的,于是降级成2.1.9,再看,一切恢复正常了,到此问题算是解决了。

这个问题是解决了,但其实遗留了好几个疑问点还不知道原因:
1. 为什么permgen一直增长/回收,会造成ygc变得越来越慢,完全无法理解呀;
2. Groovy 2.3.x到底做了什么导致了class的不断重复装载,猜想是API上做了变化,还没来得及仔细看。

有经验的同学可以帮忙告知下我,谢谢,:)

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

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

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

又一个陷入困局的case,求助

最近排查case实在是非常的不顺,又碰到了一起至今为止还无解的case,分享并顺带求助下。

这个case的现象是应用负载很低,但执行jstack或jmap都提示需要加-F来强制执行,碰到这样的现象,自己常用的一招就是先gcore pid生成下core dump,然后再用jstack/jmap去拿,jstack从core dump里提取java stack信息的时候报错了,于是只好jmap去提取内存dump信息,这个成功了,放到内部的web版的mat上一看,内存使用很正常,线程也挺正常的。

于是用pstack去看那个java的进程到底在做什么,诡异的是看到的是这个java进程正在执行cms gc,执行到MarkSweep::follow_stack这一步,一直不动,这太奇怪了,这个时候刚好应用这边的人告诉我一个信息是,卡住之前gc log里显示一直在做cms gc。

到这个阶段为止,这个现象仍然是非常的奇怪,第一次碰到一个应用一直做cms gc然后到卡死的状况,百思不得其解,在一通瞎折腾后,突然看到这个进程的状态与众不同的处于T状态,T状态表明进程处于STOPPED或TRACED状态,那就可以解释为什么会卡住了,猜想应该没人做TRACE,于是就执行了下kill -18 pid,进程恢复了,gc log里开始继续输出信息,一直在做full gc,后来查明进程进入T状态的原因是之前执行jmap后异常退出,导致进程变成T状态了,但为什么会变成这个细节目前还没去查,如果有人知道也欢迎反馈。

到这步,理论上问题就好查了,进入了典型的OOM排查模式,悲催的是dump内存,还是失败,gcore再jmap,分析后显示只占了几十M的内存,这还是不对,只好再次尝试执行jmap –dump,在dump了两次后终于成功了,拿着这个dump文件开始分析。

dominator tree显示内存主要是被三个线程占用,每个线程里占用最多的都是com.sun.tools.javac.util.ListBuffer,三个线程都是在执行com.sun.tools.javac.Main.compile中产生出来的,而且都是在compile同一个java代码。

对这块的机制不太熟,猜想莫非是多个线程compile同一段代码会出现并发问题,导致死循环了,于是自己在本机模拟写了一个多线程compile同一个java代码的测试,没碰到问题,在生产环境里也用真实环境去测试了下,也没重现。

这个case到目前仍然是这个状况,完全不明白为什么compile产生出了一个暴大的ListBuffer,不知道有没有看官们碰到过类似问题呢,求建议或帮助。

—————————–
这个case爆出后,前两天还出现了一个同学在线上执行jmap -heap,然后导致进程进入T状态,这个有可能是两个原因,一是在用cms gc的情况下,有些时候jmap -heap的输出会一直循环,然后就卡住了,另一种就是执行的时候异常退出了,所以我以前给的建议一直是不要在生产环境执行jmap -heap,jstat完全可以满足需求,而且更安全。

—————————–
上篇文章中提及到一个tomcat支持长连接的问题,里面有说到很难找到文章清晰的讲解tomcat的三种connector(apr、nio、bio)模式的工作原理,同事@宏江 同学写了一篇很不错的文章,让自己受益匪浅,推荐给大家看看,感兴趣的可以点击阅读原文

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

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

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