郑昀 汇总 20130309
常见现象的故障分析：
现象倒推一：Java Web应用的连接数暴增
最大的可能是，Web应用的线程调用路径中阻塞在某个远端资源上。
- 线程向某个远端资源发起的请求被阻塞，可能是以下原因：
- 连接受阻，如等待client端连接池的空闲连接，如远端服务连接数满；
- 响应迟迟没有返回，如数据库中的记录被“表锁”或“行锁”，如数据库有大量慢查询；
常见的连接超时时间
为了让大家一看到线上日志某些刚刚好的时间就能反应过来，总结如下：
- memcache
- PHP下，Memcache::connect 函数传入的 timeout 参数代表连接超时时间，单位秒。默认值1秒；
- 注：修改此值之前请三思，过长的连接超时时间可能会导致失去所有的缓存优势。
- Java下，
- spymemcached 里，配置 opTimeout 代表操作超时时间，默认值2.5秒；
- xmemcahced 里，opTimeout 的定义与spy 一样，默认值1秒；
- mysql
- wait_timeout：服务器关闭非交互连接之前等待活动的秒数，默认值28800秒（即8小时）；
- connect_timeout：在获取链接时，等待握手的超时时间，只在登录时有效，默认值10秒；
- innodb_lock_wait_timeout：一个 InnoDB 事务遇到一个行锁，等待的超时时间，默认值50秒，届时会打印“Lock wait timeout exceeded; try restarting transaction”错误；
- mongodb
- Java下，
- MongoOptions.maxWaitTime：连接上阻塞线程的最大等待时间，默认值120秒。
- MongoOptions.connectTimeout：建立新连接超时时间， （注意Only used for new connections） 默认无限制。
- MongoOptions.socketTimeout：socket通讯超时时间，默认无限制。
现象倒推二：Java应用频繁 fullgc
频繁 fullgc 大致有几种原因：
第一种，还是由于某一个资源成为瓶颈，导致大量线程进入 blocked 状态，新的 Requests 源源不断进入，不断开启新线程。加之线程在内存中做了很多运算，且这些内存无法收回，导致 old generation（旧生代内存区）占用比例超过阈值（此阈值由 JVM 参数 CMSInitiatingOccupancyFraction设定，默认值是90%），进一步导致新对象分配没有更多的空间，从而频繁触发 fullgc。
举例，由于某段代码没有释放数据库连接——>连接池中的连接耗尽——>部分线程无限 TIMED_WAITING ——>其余线程都 Blocked——>开启新线程——>频繁引发GC——>占用大量CPU——>应用挂起。
第二种，产生了大量大内存对象，占用了大量堆空间，引发 fullgc 。
可以将当时的 memory dump 文件经由 MAT 工具分析，找到对应的对象或直接找到类。
语录分享：
语录：
『主动沟通，要求反馈：当你接到一个新的、没有经验的任务时，首先要确认目标、时间点等具体要求(what，why，when)；在有了做事的思路和框架时和老板沟通，获取反馈(how)；在初稿完成后再次沟通获取反馈；最后才是最终成果。切忌自己闷头做到最后的时间点，此时如果结果不符合预期会很被动。』——Qiaoxin
语录：
『上周和兄弟们饭后百步走，随口一句：组织是什么？组织就是屁股。组织架构就是摆屁股，架构调整就是调整屁股。因屁股造成事情办不妥，推进不了。就该时候动手了。』——carnec
语录：
『早期项目一看团队，二看方向，但都需要打得赢。团队希望是一起打过仗的，立过战功的，有基本的默契，这样的团队继续赢的概率更大。方向打得赢则是指所在方向有大概率打得赢，至少能先站住，后站高。』——林军
语录：
『我选领导团队的四个原则：一是必须有理想有事业心有共同的价值观；二是个人能力一定要互补，不能都找能力和你相似的人，个人可以有不足，团队不能有短板；三是每个人要有独立作战独挡一面独立发展的能力，有这样的团队公司才能有发展空间；四是我管的团队不能太多人，喝酒时一桌一定要都坐得下。 』——孙宏斌
语录：
『曾在一处见到，淘宝在长期使用java构建web项目后，得出一个结论：积重难返。
实际工作经验得到的结论，积重难返的原因，往往不是java本身的缘故，而是团队成员基础积累参差不齐，许多次的“一不小心”积累成了最终的结果。到了悔之晚矣的时候自然就积重难返了。如何避免java使用自伤，最关键在于，统一团队成员的code入口，框下可能发生的事情，避开不能发生的事情』——54chen
语录：
『有人说「台风来的时候，猪都能飞起来」，公司快速成长期，每个人好像都能力都倍增，其实没有，大形势好，滥竽充数也能像个高手，所以这时候千万别忽视个人学习，否则大潮退去，越在浪头上越死在沙滩上。』——Fenng
语录『几乎每个工程师都能挑出discuz的若干不足和问题，有时候我就会从中选择一些面试题，比如discuz在ip地区识别中的一些算法函数，一些复合索引和冗余字段的设计思路，乃至用户密码随机salt的原理，一深究下去，发现应聘者基本上都回答不出来。』——caoz
语录：
『【CEO必鉴：烂苹果定律】在任何组织里，都存在几个难管理的人物，他们像苹果箱里的烂苹果，如果你不及时处理，它会迅速传染，把果箱里其他苹果也弄烂。一个不干工作，喜欢搬弄是非的人足以很快将一个高效的部门变成一盘散沙。“烂苹果”要果断清除！』——正和岛标准
语录：
『担当、责任意识和自动补位是创业团队早期必要的。而不是经常说这不是我的事、我不是管事的、需要找xxx……从0-1，从1-10，只有敢于要，敢于担当的人最后才能成为获得成就、地位、认可的人』——文昭武穆
语录：
『你遇到过很多聪明人，你的大学同学，你的同事，你的朋友，有几个比你傻？很多年以后，你会看到成功的并不是最聪明的人。因为决定成功的更多是非智力因素：明确的目标，积极的心态，努力和坚持，承受挫折和压力的能力，成熟的接人待物等等。有一种人注定没戏：不努力和怨天尤人。』——孙宏斌
语录：
『我以为，工资的定价依据，不是自己在其他地方能拿多少，而是公司花多少钱可以招到替代自己的人。』 ——邓熔
语录：
『
@孙陶然：#昆仑的仑# 一把手要对进度敏感，盯住KPI，把精力放在解决那些未达成KPI的部门上。解决问题时先看人再看事儿，人对了事儿才可能对，人不对事儿不可能对。
』
语录：
『越是在最紧要的时刻，越是考验团队：哪些人可以拉得出、扛得上；哪些人怯阵、退缩；哪些人是真正的顶梁柱，哪些人是打酱油的。请每一位想在职场上不断取得更好发展的人都要格外珍惜这样的机会，充分施展自己的才能，在关键时刻发挥关键作用，这种机会不是想有就有，甚至可能不是由团队左右，切忌掉队。
——sodme』
语录：
『
@许晓辉 ：在创业公司，不会主动找事做的人，不是原地踏步，就是会被淘汰。主动找事首先是基于本职岗位的创新和实践（这一点大多数人做不到），其次是对自己所处工作链条的完善（不必顾虑是否跨界），最后是对公司各环节的观察、思考与建议（做到这一层离晋级就不远了）。第一点最重要，有了根据地才好扩张疆域。
』
语录：
『@许晓辉：
曾经不理解老板变化无常，定下来的事怎么说变就变；等你自己做老板会发现：局势总在变化，必须随时做出调整，以应对来袭的风浪，确保航行安全。若你在创业公司，更要深刻理解这一点，理解变化背后的缘由。自此，我也深刻领会了马云的话：“真正的高手还在于制造变化，在变化来临之前变化自己。”
』
语录：
@许晓辉 ：对于跳槽频繁者（在一家公司时间低于一年）一定要谨慎，此类人大部分不是能力就是态度有问题。你不能指望自己有点石成金的魔法，也不能指望一个缺乏耐力的人能在你公司变得坚韧不拔，他可能只是以跳槽逃避困难与压力。