1、解决生产环境里的突发故障
假设现在你是一个普通的Java工程师，然后在一个团队里，平时你们开发系统都有一套成熟的框架和技术体系，比如说微服务框架用Dubbo，然后另外涉及到了Redis缓存、RocketMQ作为消息系统、数据库中间件。
平时正常开发都没多大问题，就是基于Dubbo写一些服务，然后在里面填充业务逻辑就OK。
也许有时候架构设计会用到Redis，也可能会用到RocketMQ，也会用到数据库中间件来做分库分表的事情，这都没问题，按需引入。
但是事情却没有想象中一般顺利，数据库中间件在进行分库分表操作时，不时出现一些诡异的情况。
什么情况呢？
明明SQL执行成功了，结果数据就是没进入数据库；明明数据库里有数据，但是SQL执行之后，却查不出来数据。
这个时候就很麻烦了，大家肯定都知道，数据库层面有问题，对业务是影响非常大的。
那谁能解决这个问题？
答案是：你公司必须得有一个精通数据库中间件源码的专家，否则这种数据库问题基本上无解。
或者就算解决了，那也是瞎猫碰上死耗子，而你运气，不会每次都这么好吧！
为什么说基本无解呢？因为这种生产问题，涉及到了一个中间件底层的执行机制。
那么你必须深入研究过源码，将出问题时候的数据库现场和SQL还原出来，在本地调试，然后一点点看源码执行的过程，到底为什么会出问题。只有这样才能解决这种生产问题。
所以能够读自己系统中用到的开源项目的源码，非常重要。如果你能做到这一点，就可以在混乱的生产故障中，挺身而出，解决线上问题。
并且这种重大生产故障现场，你如果多次出镜，怎能不得到领导的青睐？而你的职业发展之路，自然的会平坦顺畅很多！
2、对棘手的线上性能问题进行优化
再来看一个场景，现在你们的系统用到了Elasticsearch，结果刚开始以为分布式系统肯定可以存储大量的数据，然后高性能的检索。
前面半句没问题，存储大量数据是肯定可以做到的，但是后面半句有问题，高性能的检索，还真的不一定。
Elasticsearch现在非常的火，很多公司都在用，而且一下子会往里面放入大量的数据。
但是问题就在于这里，放入大量数据之后，很多公司发现ES搜索性能特别的差，经常出现要好几秒，甚至几十秒，几分钟才能查出来的情况。
所以对这种性能问题，如果只是网上查查博客，胡乱调节一下参数，这儿试一下，那儿试一下，其实没多大用处。即使调好了，也就是前面说的，瞎猫碰上死耗子。
最主要的，还是要真正的分析性能问题的瓶颈，也就是要深入分析ES的源码，你需要搞明白通过 ES执行一个搜索时，底层到底怎么执行的，性能瓶颈到底在哪里，然后才能针对性的去进行性能的优化。
假设现在ES导致你公司的APP用户搜索的速度特别慢，被大量用户投诉，此时CEO施压给技术团队，技术团队急的团团转。
此时要是你挺身而出，通过源码分析，解决了这个问题，优化了性能，凭借一己之力力挽狂澜，carry全场，那毫无疑问你一下子就能脱颖而出。
领导都喜欢能打仗的技术骨干，中间力量，有问题直接派你上去就能搞定，这个时候升职、加薪一定会把好机会都留给你。
3、码农激烈竞争中的核心竞争力
现在假如你要出去找工作，然后同一个职位有好多人竞争，这些人都有以下一些共同的属性：
-
5年以上的工作经验，或大或小的公司都待过，项目经验都还可以
-
常见的技术栈掌握的都还可以，Java、并发、IO、ES、MQ、缓存、大数据量，等等
-
或多或少都带过一两个人，独立负责过一些项目
说句题外话，
其实中国的IT、互联网发展到今天，人才储备可以说很充足了，毕竟每年都有大量的计算机专业的毕业生，还有很多的培训机构在输送大量的人才，这些初级人才经过多年发展之后，基本上都具备以上特征。
因此现在好的职位，竞争是极其激烈的。如果在去年下半年或者今年上半年跳槽过的朋友，应该多少会有一些体会！
那么在这种激烈的竞争中，你凭什么力压群雄，拿下一个大厂的职位呢？
答案是两个：
1、是否对你用过的技术进行过深入挖掘。
