小言_互联网的博客

Java工程师的成长路线图是什么?

262人阅读  评论(0)

我经常能听到一些同学困惑,“面试造火箭,天天拧螺丝”,每天进行重复的业务开发,似乎自己的能力被日常工作限制,无法突破提高自己的能力水平。

 

我想说,难道懂得如何造火箭,还能没有实际价值吗?它的价值在于,当真的出现不可预测的、具有挑战性的任务时,你能不能 Hold 住。

 

比如说,有个周末,我被着急拉去优化一个 Go 语言开发的系统,马上要上线了但实际吞吐量与需求有数量级差距。对,你没看错,不是 Java 应用,而且我对 Go 的了解基本就是 HelloWorld 水平。下面我简单介绍一下,如何利用基础知识,快速定位问题,并通过两个代码量有限地修改,实现吞吐量的数量级提高。

  • 初始的表现是,非常低的负载下,CPU 利用率就已经超过 80%。首先,通过第 33 讲的类似过程,定位问题在于低效实现导致的高 CPU 占用问题,利用 Go Profiling 发现热点代码,据此快速查出一个最频繁操作的算法复杂度是 nlogn。

  • 修改为 logn 复杂度算法后,系统又表现出了新的特征,随着负载压力的提高,CPU 利用率无法超过 60%,内存、I/O 也还有很大余量,吞吐量虽然已经有数量级提高,但还是达不到设计目标。

  • 进一步分析发现在某共享模块,竟然有可观的同步开销,原来不必要的共享以及其实现内部采用的一些线程安全手段,限制了系统的扩展性。将该模块修改为非共享实例后,CPU/ 内存等计算资源就得到了充分利用,吞吐量基本达到理论峰值。

这个问题本身难度并不是很高,使用的也是基础知识和技能,但也能说明掌握扎实的“基本功”,可以让你剥开问题的表象,感受到技术本质的价值所在。

 

但是,我发现很多技术人不具备这种“解决问题”的能力,我觉得主要是以下 2 个原因:

 

第一,“知其然不知其所以然”。做了多年技术,开发了很多业务应用,但似乎并未思考过种种技术选择背后的逻辑

 

第二,知识碎片化,不成系统。无法完整、清晰地描述自己所开发的系统,或者使用的相关技术。

 

 

所有,我特地刷脸找极客时间的运营小姐姐,要到了《Java 核心技术 36 讲》专栏的优惠,这门课可以让你可以透过问题看到本质,提高“解决问题”能力。在专栏里,作者从 Java 核心知识点和能力出发,精选出 36 道 Java 面试题。每期针对 1 道题目,不仅会给出典型回答和考点分析,还会剖析 Java 核心知识点,将其讲清讲透,让你彻底领悟题目背后所考察的能力,帮你梳理复习 Java 知识体系。不管你是在准备面试、还是想进阶 Java,你都可以通过这个专栏,提升 Java 技能

 

∆扫码试看或订阅

 

 

“德雷福斯模型”是一个常见的能力、水平划分方法,我们可以试着把 Java 工程师划分为新手、高级新手、胜任者、精通者和专家。

那如何找到自己所处的能力水平,通过学习和实践实现进阶呢?

 

 

新手阶段

 

如果你是新手阶段,全面、扎实地掌握语言的基本要素是当务之急。在这个阶段我认为是有无限可能的,因此我并不建议完全用《Java 核心技术 36 讲》专栏作为 Java 语言入门的课程,而是更应该找到更基础的、系统的 Java 书籍或者课程。

 

你可以在正规的指导下飞速进步,并培养出良好的编码习惯。然后可以再结合专栏,看看 Java 技术领域典型的、长期的热点话题,了解业界通常从哪些角度判断你的能力和水平。

 

你可以从专栏的基础模块,看到 Java 领域长期的热点话题(十年前面试就会问,一直问到今天),比如:

  • 第 2 讲 | Exception 和 Error 有什么区别?

  • 第 3 讲 | 谈谈 final、finally、finalize 有什么不同?

  • 第 4 讲 | 强引用、软引用、弱引用、幻象引用有什么区别?

高级新手

 

工作了几年,整天忙于业务代码,很容易困惑下一步的方向在哪里,相当多的程序员长期停留在高级新手的阶段。一个常见的表现就是发展成为了“面向搜索引擎”编程工程师,擅长快速利用开源项目或者以往成果,完成一些“OK”的工程任务。这本无可厚非,职业路线很多,未必每个人都想成为底层专家。

但是,如果想在技术领域更进一步,一定要避免下面两个问题。

  • 面对没见过的、一定规模的或者较高标准的问题时无所适从,具体表现为“领导,你看这样行吗?”。没做过互联网高并发应用,难道就不能对并发编程有相对深入的思考吗?比如,习惯了使用 Executors,你有没有思考过不同的线程池到底适合什么场景?当前的实现在未来业务量增长下可能出现什么问题?(参考第 21 讲 | Java 并发类库提供的线程池有哪几种?分别有什么特点?)

  • 无法独立提供有说服力的、有深度的分析、设计和实现,比如业务系统运行一段时间就变慢,调整 Heap 大小,似乎仍然 OOM。目前团队处理的方式就是重启服务器,有没有想过去发掘真正的原因,真正去解决它?(参考第 26 讲 | 如何监控和诊断 JVM 堆内和堆外内存的使用?)

另外,我也推荐你看看专栏里这些内容:

  • 第 6 讲 | 动态代理是基于什么原理?

  • 第 9 讲 | 对比 Hashtable、HashMap、TreeMap 有什么不同?

  • 第 11 讲 | Java 提供了哪些 IO 方式?NIO 如何实现多路复用?

  • 第 18 讲 | 什么情况下 Java 会产生死锁?如何定位、修复?

  • 第 27 讲 | Java 常见的垃圾收集器有哪些?

我建议不要满足于这些表面的特征,要学会用白盒的视角看待技术内部,系统性的思路掌握普遍规律。即使未来你不在一线编码,或者未来不再使用 Java,同样的思维习惯和积累也是很有帮助的。

 

∆扫码试看或订阅

 

 

胜任者

 

那如何才能算是摆脱了高级新手的阶段呢?或者换句话说,如何成长为团队的核心成员?这取决于你能背多大的锅、填多大的坑,比如你已经可以:

  • 独立负责做 GC 调优,即使没有历史经验,也能给出有说服力的方案。(参考第 28 讲 | 谈谈你的 GC 调优思路?)

  • 在 JVM 领域有充足的技术经验和知识储备。(第 25 讲 | 谈谈 JVM 内存区域的划分)

  • 全面评估评估后台变慢等问题的复杂度、风险点、解决的可能性。(参考第 33 讲 |Java 后台服务明显变慢,谈谈你的诊断思路?)

  • 对于所谓本质的思考和理解,能听懂深入的抽象观点。

并且,除了 Java/JVM,还要掌握更完整的技能树,例如分布式系统设计、数据库隔离级别选型等。

 

另外,我也推荐你看看专栏里这些内容:

  • 第 39 讲 | 谈谈常用的分布式 ID 的设计方案?Snowflake 是否受冬令时切换影响?

  • 第 36 讲 | 谈谈 MySQL 支持的事务隔离级别,悲观锁和乐观锁的原理和应用场景?

其实,《Java 核心技术 36 讲》专栏的内容也是为了提醒胜任者,在实际工作中往往不会界限分明,团队核心往往要能够 Hold 住不同技术领域、切换不同角色,比如架构设计、核心代码开发、紧急线上问题攻关等。

掌握将“OK”的事情做到“excellent”程度的能力,不断地进行高效实践、领域的扩展和精深,我们就可以达到并超过胜任者,逐步成为精通者和专家。

 

精通者和专家

 

如果你已经精通 Java 语言或者是特定领域的专家了,那这个专栏对你的帮助可能体现在不同角度,可以当作特定领域的、不同视角吧。例如,在这个阶段,精通者或专家能够:

  • 提炼并发工具类的一般性指导方法。(参考第 19 讲 | Java 并发包提供了哪些并发工具类?)

  • 告诉团队如何写出安全的 Java 代码,防范看似安全下隐藏的风险。(参考第 32 讲 | 如何写出安全的 Java 代码?)

  • 借鉴 Java/JVM 中的一些技术,从基础能力上提高自身平台的能力。例如,PHP 7 中引入的 JIT,带来了极大的性能提升,第 35 讲中对 JIT 的介绍,就有了新的用武之地。(参考第 35 讲 | JVM 优化 Java 代码时都做了什么?)

  • 如何通过 Container-Aware 技术,提高 Kubernetes 集群中 JVM 负载的可靠性。(参考第 30 讲 | Java 程序运行在 Docker 等容器环境有哪些新问题?)

  • 创造某一类问题的解决方法。例如,似乎 Java 工程师动不动就是 Happen-Before,除了耍酷,能不能从更高的高度看待:JMM 是如何实现了编译器工程师、JVM 工程师、Java 开发者甚至不同厂商之间的一致性规范?如何创造性地避免了早期 C++ 内存模型在不同厂商之间的混乱?(参考第 29 讲 | Java 内存模型中的 happen-before 是什么?)

限时福利

 

《Java 核心技术 36 讲》已有4w+人学习。今天我领衔超级团只需79元,原价99元,仅限100人,绝对最低价,限时24小时,别错过了。

 

∆扫码试看或订阅

 

专栏读者评价

 

专栏订阅量稳居极客时间 Top 3,好评多多,部分如下:

 

             

 

专栏目录

       

点「阅读原文」,最低价订阅《Java 核心技术 36 讲》。

                        点个好看,少个 bug👇


转载:https://blog.csdn.net/hollis_chuang/article/details/100980685
查看评论
* 以上用户言论只代表其个人观点,不代表本网站的观点或立场