25年10月得物 JAVA开发一面

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

死锁发生的四个必要条件是什么？平时写多线程代码时，你会怎么主动避开这些坑？

“四个必要条件：互斥条件、请求与保持、不可剥夺、循环等待。
主动避坑三招：
1️⃣ 固定加锁顺序：项目中所有涉及userLock和orderLock的操作，强制约定先加userLock再加orderLock（代码规范+Checkstyle插件校验）
2️⃣ 超时放弃：ReentrantLock.tryLock(3, TimeUnit.SECONDS)，超时直接释放已持锁并告警
3️⃣ 避免嵌套锁：将大锁拆为细粒度锁（如订单状态更新单独加锁），用ConcurrentHashMap替代synchronized Map
心得：写多线程代码前必画‘锁依赖图’，循环依赖=死锁预警。”

除了破坏必要条件，项目里还用过哪些防死锁的小技巧？

“三招实战技巧：
🔹 锁超时熔断：自定义注解@LockTimeout(seconds=5)，AOP环绕处理超时异常
🔹 死锁监控：定时线程调用ThreadMXBean.findDeadlockedThreads()，发现死锁自动dump线程栈+企业微信告警
🔹 工具替代：

计数场景用LongAdder替代synchronized

缓存用Caffeine（内部无锁设计）
案例：OJ系统判题队列曾因双锁嵌套偶发卡顿，改用BlockingQueue+单消费者线程后彻底解决。”

Java线程有哪几种状态？能说说它们之间怎么转换的吗？

“六种状态及关键转换：

当前状态触发动作转换目标

NEW start() RUNNABLE

RUNNABLE 等待synchronized锁 BLOCKED

RUNNABLE wait()/join() WAITING

RUNNABLE sleep(1000)/wait(1000) TIMED_WAITING

BLOCKED 获得锁 RUNNABLE

WAITING notify()/interrupt() BLOCKED（需竞争锁）

当前状态	触发动作	转换目标
NEW	start()	RUNNABLE
RUNNABLE	等待synchronized锁	BLOCKED
RUNNABLE	wait()/join()	WAITING
RUNNABLE	sleep(1000)/wait(1000)	TIMED_WAITING
BLOCKED	获得锁	RUNNABLE
WAITING	notify()/interrupt()	BLOCKED（需竞争锁）

| 任意 | 任务完成/异常 | TERMINATED |
项目验证：用Arthas thread -b快速定位BLOCKED线程，曾通过此命令10分钟内解决线上线程阻塞问题。”

在浏览器输入URL到页面出来，整个过程发生了啥？

“聚焦网络与后端：
1️⃣ DNS解析：浏览器查本地Hosts→DNS缓存→递归查询（得物用HTTPDNS防劫持）
2️⃣ TCP三次握手：客户端SYN→服务端SYN+ACK→客户端ACK（得物TLS 1.3优化为1-RTT）
3️⃣ HTTP请求：

Nginx负载均衡（加权轮询）→ 网关（鉴权/限流）→ 业务服务

得物特色：静态资源走CDN（图片/JS），动态请求经API网关
4️⃣ 服务处理：

Spring Boot应用：Filter→Interceptor→Controller→Service→DB/Redis

关键优化：热点数据（商品详情）走本地缓存（Caffeine）+ Redis
5️⃣ 响应返回：JSON数据经网关压缩（Gzip）→ 浏览器解析渲染
延伸思考：得物高并发场景下，DNS预解析、TCP Fast Open、HTTP/2多路复用都是关键优化点。”

一个HTTP请求打到服务端，中间经历了哪些关键步骤？

“以Spring Boot应用为例：
1️⃣ 容器层：Tomcat Connector接收 → 创建Request/Response对象
2️⃣ 过滤链：

CharacterEncodingFilter（统一UTF-8）

CorsFilter（跨域处理）
3️⃣ Spring层：

DispatcherServlet分发

HandlerMapping找Controller

Interceptor.preHandle（Token校验）
4️⃣ 业务层：

Controller参数校验（@Valid）

Service层事务管理（@Transactional）

Mapper执行SQL（MyBatis）
5️⃣ 返回链：

Interceptor.postHandle → View渲染

Filter链后置处理（日志记录耗时）
项目细节：自定义LogFilter记录traceId，串联全链路日志，排查问题效率提升50%。”

负载均衡常见策略有哪些？项目里用过哪种？为啥选它？

"| 策略 | 适用场景 | 项目选择 |
|------|-----------|-----------|
| 轮询 | 服务器性能均衡 | ❌ |
| 加权轮询 | 服务器配置差异大 | ✅ OJ系统Nginx配置 |
| 最小连接数 | 长连接场景 | ❌ |
| IP哈希 | 需会话保持 | ❌ |
选型理由：

判题服务器A（8核）权重=3，B（4核）权重=1

配置：upstream judge_server { server A weight=3; server B weight=1; }

效果：资源利用率提升40%，避免小服务器过载
认知：策略无优劣，匹配业务场景是关键。”