一. 性能调优
几乎每个JAVA后端开发程序员,都会在面试时碰到诸如如何性能调优的问题,如何回答好这个问题,不仅仅是考察对JVM,内存模型等的理解,更看中的是碰到性能问题时,排查问题的方法论和思路。
典型的一个场景是:在压力测试时,发现FullGC频率很高,如何解决?
此类问题一般从以下几点入手:
观察GC日志,判断是否有内存泄漏,或者存在的内部不合理点。此处要求能熟悉各种linux命令,可以快速查看和定位。
调整JVM 参数,如新生代,年老代大小,S0和S1大小比例,不同垃圾回收器的采用。并结合业务特点做进一步分析。这里不但要求扎实的JVM内存模型和理论,还要求对JVM的各种参数设置耳熟能详,并能实践操作。
Dump内存,做进一步的对象分析。
压测脚本的编写,性能问题解决前可以发现问题,并能在问题解决后真实的验证。
此类优化不能用照本宣科式的回答,面试官一定会问实际中操作的场景,和解决问题的思路。虽然性能问题的原因是多种多样的,但是解决问题的思路和方法论是可以明确的。
二. 网络框架的理解和使用
大家一定都听过或使用过网络异步框架Netty,甚至使用netty框架开发过一些应用和功能。
但是大部分人仅限于对Netty的使用,甚至仅仅知道其他一些开源框架使用了Netty,但是在资深面试官眼里,Netty有很多值得学习和借鉴的地方,使用过Netty并且能对Netty的一些原理有一定的了解且能学以致用的Java程序员格外受欢迎。
一般来说,要求较高的面试官和技术经理喜欢从Netty的设计模式角度深入的考察技术人员对网络开发和相关理论的理解如:
Netty的Reactor模型如何设计,反应在应用里的模型是如何(见下图)。
Java高级架构师,都需要掌握哪些技术栈?
Netty的pipeline 责任链如何使用,业务场景中是否有类似的实践经验。
项目中有无使用Netty,并利用Netty进行私有化协议设计。
同学们不仅要求能使用Netty,通过阅读其源码,理解其中的精髓,并能应用在自己的实践项目中,这个才是亮点和加分项。
三. 开源服务化RPC框架的理解和使用
互联网经过十几年的发展,早已经从单体应用发展为服务化应用,大厂里系统和服务尤其如此。
拿经典的dubbo 服务化框架举例,当前市面上有很多dubbo相关的文章和介绍,这里撇开不谈,从技术负责人的角度来,我会更关心下面有关几个dubbo相关的问题。
技术选型:为什么选择dubbo,而不选择其他如spring cloud框架?
我认为可以从如下考虑:
A)业务的特点以及可预见的后续的发展。作为高级技术人员,必须需要对业务的的发展做预计和规划。
B)可用性要求,是否需要达到4个99(99.99%),需要支撑的峰值QPS,是否有业务的集中爆发点,如电商大促
C)团队的成熟度,一个成熟的团队可以很好的hold住复杂的开源框架,甚至做定制化开发。
技术选型话题虽然宽泛,但是最能体现体现技术人员的综合能力,尤其结合业务特点后对技术框架深度和广度的驾驭能力。
Dubbo底层走的是什么协议,如何处理异步转同步?
大部分的Java开发都会直接使用dubbo,而不会去关心其底层一些技术细节,但是一些细节,如dubbo如何对对象进行序列化,用了哪些序列化方式,这些在分布式项目中对提高应用的处理速度,减少网络开销,都很大帮助。
同时RPC框架里如何将异步转同步,也是需要技术人员非常关注的一面,里面相关的设计模式,多线程程高并发场景都是很多业务系统里真实需要和借鉴的。
Dubbo在高并发高可用等实践场景需要认真考虑的其他问题
使用了dubbo后,很多人觉得万事大吉,其实并不是这样,下面几点还需要关心,并且这些就是体现你价值的地方
A) dubbo依赖了zooKeeper,但是万一ZooKeeper宕机了怎么办
B) 如果ZooKeeper假死,客户端对服务端的调用是否会全部下线,如果是该如何避免
C) 如何监控duubo的调用,并做到优雅的客户端无感发布
同学们可以自行思考,答案不是唯一,网易有很多类似的项目,设计的很好,非常值得思考和借鉴。
自身多年的面试体会
1.项目中尽量多思考,迎难而上,如碰到复杂的性能,内存泄露等问题的问题,往往是提升自己的机会,千万要仔细研究解决,可以参考其他解决类似问题的文章和实践经验,对技术深度的提升是很大的,关键时候可以让你的面试官突然觉得面耳目一新。
2.重视解决问题的思路和方法,很多时候技术人员可以快速设计一个系统或解决一个问题,但是在资深工程师或面试官眼里可能并不是最优方案。如何解决?
很多技术人员的项目和技术相对单一,长久以往,容易造成技术思路和视野的狭窄,接触不到行业最新思路和动态或者当前疑难问题的最佳解决方案。
————————————————
版权声明:本文为CSDN博主「qf2019」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qf2019/article/details/92577531