知乎上有一个热门问题：你的编程能力从什么时候开始突飞猛进？
初看到这个问题，我的嘴角微微上扬。记忆闪回到了年，那一年，命运给我了一点点正反馈，我有点喜欢编程了。
这篇文章，我想和大家聊聊勇哥读书，看源码，重构，解决线上问题的那些事。
1.初心
年，我服务于一家互联网彩票公司。坦率的讲，选择程序员这个职业，仅仅是为了生存。
那个时候，我对缓存，消息队列，分布式，JVM一知半解，背了一些八股文，只是能非常熟练的使用ibatis，velocity，编写简单的业务代码。
我负责的是用户中心系统，提供用户注册，查询，修改等基础功能。所有的服务都以HTTP接口形式提供，数据传输格式是XML。
虽然工作看起来简单，我那个时候也不懂设计模式，写的业务代码非常臃肿，难以维护。
也发生了我的人生第一次重大BUG，我负责的用户中心在上线后隔一段时间变会内存溢出。我站在运维同学那里，看着他调整tomcatjvm参数，不知所措。
后来发现我在使用ibatis的时候，使用类似的SQLMap，前端又没有验证，数据库执行了全表查询，从而导致JVMOOM。
select*fromt_lottery_usertwhere1=1isNotEmptyprepend="AND"property="userName"user_name=#userName#/isNotEmptyisNotEmptyprepend="AND"property="id"id=#id#/isNotEmpty....
这次生产环境事故之后，内心一直有一个声音折磨着我：“遇到技术问题的时候，能不能从容一点，不慌乱。其他人可以做到的事，为什么我做不到。”
于是我开始疯狂的买书读书，毕玄老师的《分布式Java应用》这本书对我影响至深。通过这本书，我深入学习了JVM内存模型，核心集合类原理，并发包等知识点，特别是jstack，jmap等JVM命令，边看书，边动手实践。
同时为了扩展视野，我在javaeye和开源中国两大社区里面疯狂找热门帖子学习，一个帖子上下文都我都会反反复复的看几十遍以上。
也时不时找运维同学，或者DBA聊，因为和他们聊，可以从另外一个视角审视公司系统存在的问题，他们的一句话有时候可以给我一些灵感。
2.第一次重构
经过-两年的学习，年彩票业务迎来了小爆发，我也迎来了技术人生第一次重构。
算奖服务是非常核心的服务，算奖服务包含若干子服务，其中竞彩算奖是用C#版本开发的系统。原来彩票订单量少的时候，算奖服务还算稳定，但一旦量级增大，C#版算奖服务就会hang住，算奖时间从半个小时变成两三小时，严重影响订单的返奖。
我当时满脑子都是想着去争一口气，去证明自己已不是两年前的弱鸡，于是主动请缨重构算奖系统。但领导说实话也是半信半疑，当时情况比较紧急，于是也就同意了。
技术团队比较草莽，没有统一的基础框架，每次新建项目都是按照研发的喜好搭架子。因为原来有接触过京东的基础框架，于是我参考京东框架第一次搭建自己的作品。
算奖整体逻辑比较简单，服务接收到竞彩赛事编号，查询彩票子订单，通过赛事结果判断彩票是否中奖，并修改子订单中奖信息，最后发送中奖信息到消息队列，最后调度中心来返奖。
至今都还记得开始写代码是双休日，两天没日没夜不知疲倦的编码，指尖敲击键盘，代码显示在屏幕上，行云流水，这种感觉美好而又奇妙。
两天就重构完了，怎么验证正确？在测试环境简单跑了一遍，发现没有任何问题。领导也觉得不可思议，但这个就能上线吗？我心里面也直打鼓，每天的竞彩算奖涉及到大几十万人民币，要是算错了，那影响也很大，我也要承担相应的责任。
领导也没有给我指导建议，于是我突发奇想："生产环境不是有一两年的订单算奖历史数据吗？重构版本计算的结果和生产环境计算的结果做个对比，不就可以验证正确率吗？"。
于是，我将代码做了一些微调，将最后对数据的写操作去掉，对比重构版本计算的金额和c#版本计算的金额，若金额有差异，订单数据写入到文本中，发送邮件告警。
让我惊喜的是：在近千万的历史订单里，重构版本的计算结果非常精准，只出现了两例计算异常，并且计算速度非常快(快接近10倍)。修复完BUG后，和C#版本并行运行二十天左右后，计算结果都精准无误。于是，领导同意了下线老系统，上线算奖重构版本。
这一次成功重构带给我自信：在这个行业，我是可以生存下去的。
技术层面：我自己搭建了项目，接触了消息队列做为消息总线的架构模式，也认识到应用基础框架的重要性。同时，我也隐约觉得：“代码写出来是相对容易的，验证代码的正确性同样非常考验工程能力”。
3.阅读源码
年，是我阅读源码的起点,阅读了Druid,Cobar,Xmemcached等源码。
3.1数据源连接池Druid
算奖系统重构之后，有一个小插曲。我发现每天的第一次请求，数据库连接有问题，于是我向Druid的作者温少写了一封邮件。
温少给我回复了邮件，我马上翻开源码，发现我配置数据库连接池的心跳有问题。核心点在于需要连接池每隔一段时间发送心跳包到oracle服务器，因为数据库为了节省资源,每隔一段时间会关闭掉长期没有读写的连接。所以客户端必须每隔一段时间发送心跳包到服务端。
这次简单的探寻源码给了我长久的激励，也让我更加