25年10月得物 JAVA开发二面

#JAVA##JAVA面经##JAVA内推#

1. 死锁排查时，你最常用的JDK命令是什么？

回答思路

锚定核心命令：优先选最直接、高频的 jstack（JVM 堆栈跟踪工具）；

解释核心逻辑：jstack <进程ID> 可打印线程堆栈信息，其中会明确标注「Deadlock」死锁位置，以及死锁线程持有的锁、等待的锁；

补充辅助命令：可提 jps（查进程ID）、jconsole/jvisualvm（可视化工具），但核心是 jstack；

举例：执行 jstack 12345 > deadlock.log，在日志中搜索「Deadlock」定位死锁线程及锁资源；

核心结论：最常用 jstack，直接输出线程堆栈和死锁信息，是排查死锁的核心命令。

标准答案 最常用的是 jstack 命令。通过 jstack <进程ID> 打印线程堆栈信息，日志中会明确标注死锁（Deadlock）相关线程、持有的锁和等待的锁，能快速定位死锁原因；辅助用 jps 先获取进程ID。

2. 线程WAITING状态和TIMED_WAITING状态最核心的区别是什么？

回答思路

锚定核心维度：是否有等待超时时间；

拆解区别： ✅ WAITING（无限等待）：线程等待被其他线程显式唤醒（如 Object.wait()、LockSupport.park()），无超时时间，若不被唤醒会永久等待； ✅ TIMED_WAITING（计时等待）：线程等待有明确超时时间（如 Object.wait(1000)、Thread.sleep(1000)、LockSupport.parkNanos()），超时后自动唤醒；

举例：obj.wait() 进入 WAITING，需 obj.notify() 唤醒；obj.wait(3000) 进入 TIMED_WAITING，3秒后自动唤醒；

核心结论：核心是是否有超时时间，WAITING 无限等待需显式唤醒，TIMED_WAITING 超时自动唤醒。

标准答案 核心区别是「是否有等待超时时间」：WAITING 是无限等待状态，需其他线程显式唤醒（如 notify()）；TIMED_WAITING 是计时等待，有明确超时时间，超时后线程自动唤醒，无需显式通知。

3. URL请求过程中，DNS解析的核心作用是什么？

回答思路

锚定核心：域名与IP地址的映射转换；

解释逻辑：

网络通信基于IP地址，但用户输入的是域名（如 www.baidu.com），DNS解析将域名转换为对应的IP地址；

核心是解决「域名易记但无法直接通信，IP可通信但难记忆」的矛盾；

补充：DNS解析是分层缓存的（本地→运营商→根服务器），提升解析效率；

核心结论：核心作用是将易记的域名转换为可用于网络通信的IP地址，建立域名到IP的映射。

标准答案 DNS解析的核心作用是将用户输入的域名（如 www.baidu.com）转换为对应的IP地址。因为网络通信依赖IP地址，而域名仅为方便记忆，DNS解析是实现域名访问的核心环节。

4. 服务端处理请求时，Tomcat的Connector组件核心职责是什么？

回答思路

锚定核心定位：Tomcat的通信入口，负责网络连接与协议解析；

拆解职责：

监听指定端口（如8080），接收客户端的TCP连接；

解析HTTP协议（请求行、请求头、请求体），将原始字节流转换为Tomcat内部的 Request/Response 对象；

将解析后的请求交给Engine/Host/Context等容器处理，处理完成后将响应转换为字节流返回给客户端；

举例：客户端发送HTTP请求，Connector先接收连接、解析请求参数，再交给Servlet处理；

核心结论：核心是监听端口、处理网络连接、解析HTTP协议，是Tomcat与客户端通信的核心桥梁。

标准答案 Connector是Tomcat处理网络请求的核心组件，核心职责是：监听指定端口接收客户端TCP连接，解析HTTP协议（将字节流转为Request对象），将请求转发给Tomcat容器处理，最终将响应转换为字节流返回给客户端。

5. 负载均衡中，轮询算法的核心缺陷是什么？

回答思路

锚定核心缺陷：未考虑后端服务器的性能/负载差异，导致负载不均；

解释逻辑：

轮询算法按固定顺序（如服务器A→B→C→A）分配请求，假设A性能差（CPU 100%）、C性能好（CPU 10%），仍会均分请求；

缺陷导致：性能差的服务器堆积请求，响应慢；性能好的服务器资源闲置，整体集群吞吐量下降；

补充：对比加权轮询（优化方案），但核心说轮询的缺陷；

核心结论：核心缺陷是无差别分配请求，忽略后端服务器的性能、负载、健康状态差异，导致集群负载不均衡。

标准答案 轮询算法的核心缺陷是「无差别分配请求」：仅按固定顺序轮流分发请求，未考虑后端服务器的性能、当前负载、健康状态差异，导致性能差的服务器堆积请求，性能好的服务器资源闲置，整体负载不均衡。

6. 设计RPC框架时，序列化模块最优先考虑的因素是什么？

回答思路

锚定核心因素：序列化后的体积 + 序列化/反序列化效率 + 兼容性（优先「效率+体积」）；

解释逻辑：

RPC核心是跨网络传输数据，序列化体积小→网络IO少，效率高→接口响应快；

兼容性（如跨语言、跨版本）是基础，但优先保证性能（体积+效率），否则会成为RPC性能瓶颈；

举例：对比JSON（体积大、效率低）和Protobuf（体积小、效率高），RPC框架优先选Protobuf；

核心结论：最优先考虑「序列化/反序列化效率」和「序列化后的数据体积」，这是决定RPC传