Android开发实战讲解！腾讯，字节等大厂面试真题汇总，全套教学资料

前言

什么是危机？感觉周围的人都在危机，甚至包括一些财富、地位都已经很高的人，仍然逃不过焦虑。似乎焦虑就是自然而然的，伴随着每个人的成长。焦虑多了，就开始危机了。

一些感想：我想在这里写一些感想，可能对各年龄段的朋友都有一些帮助。其实很多人真到这个年龄，见识和能力都已经很厉害了，我帮忙总结一下。前段时间有好朋友和我说，感觉随着年龄增长，会有焦虑。因为年龄越大，会发现技能上面并没有比年轻人高太多，体力和精力可能还要差一些。这样的问题迟早大家都会遇到，无论是在职场中工作了很久，还是刚入职场，有些事实，业务应该早一些了解。分享一下我自己的观察和思考，对于所有年龄在增加的企业里的中层，以及未来要成为中层的大家

学会深入思考，总结沉淀

我想说的第一条就是要学会深入思考，总结沉淀，这是我觉得最重要也是最有意义的一件事。

‌先来说深入思考。在程序员这个圈子里，常能听到一些言论：我这个工作一点技术含量都没有，每天就CRUD，再写写if-else，这TM能让我学到什么东西？

抛开一部分调侃和戏谑的论调不谈，这可能确实是一部分同学的真实想法，至少曾经的我，就这么认为过。

后来随着工作经验的积累，加上和一些高level的同学交流探讨之后，我发现这个想法其实是非常错误的。之所以出现没什么可学的这样的看法，基本上是思维懒惰的结果。

任何一件看起来很不起眼的小事，只要进行深入思考，稍微纵向挖深或者横向拓宽一下，都是足以让人沉溺的知识海洋。

‌举一个例子。某次有个同学跟我说，这周有个服务OOM了，查了一周发现有个地方defer写的有问题，改了几行代码上线修复了，周报都没法写。

可能大家也遇到过这样的场景，还算是有一定的代表性。其实就查bug这件事来说，是一个发现问题，排查问题，解决问题的过程，包含了触发、定位、复现、根因、修复、复盘等诸多步骤。

花了一周来做这件事，一定有不断尝试与纠错的过程，这里面其实就有很多思考的空间。比如说定位，如何缩小范围的？走了哪些弯路？用了哪些分析工具？

**比如说根因，**可以研究的点起码有linux的OOM，k8s的OOM，go的内存管理，defer机制，函数闭包的原理等等。如果这些真的都不涉及，仍然花了一周时间做这件事，那复盘应该会有很多思考，提出来几十个WHY没问题吧…

**‌再来说下总结沉淀。**这个我觉得也是大多数程序员比较欠缺的地方，只顾埋头干活，可以把一件事做的很好。但是几乎从来不做抽象总结，以至于工作好几年了，所掌握的知识还是零星的几点，不成体系，不仅容易遗忘，而且造成自己视野比较窄，看问题比较局限。

**适时地做一些总结沉淀是很重要的，这是一个从术到道的过程，会让自己看问题的角度更广，层次更高。**遇到同类型的问题，可以按照总结好的方法论，系统化、层次化地推进和解决。

‌还是举一个例子。做后台服务，今天优化了1G内存，明天优化了50%的读写耗时，是不是可以做一下性能优化的总结？

比如说在应用层，可以管理服务对接的应用方，梳理他们访问的合理性；在架构层，可以做缓存、预处理、读写分离、异步、并行等等；在代码层，可以做的事情更多了，资源池化、对象复用、无锁化设计、大key拆分、延迟处理、编码压缩、gc调优还有各种语言相关的高性能实践…

等下次再遇到需要性能优化的场景，一整套思路立马就能套用过来了，剩下的就是工具和实操的事儿了。大家也可以关注微信公众号：Java技术栈，在后台回复：架构，可以获取我整理的 N 篇 Java 架构教程，都是干货。

‌还有的同学说了，我就每天跟PM撕撕逼，做做需求，也不做性能优化啊。先不讨论是否可以搞性能优化，单就做业务需求来讲，也有可以总结的地方。比如说，如何做系统建设？系统核心能力，系统边界，系统瓶颈，服务分层拆分，服务治理这些问题有思考过吗？

每天跟PM讨论需求，那作为技