Java 终面追问实录：HashMap 底层、Spring 理念与 Snowflake 分布式 ID

相比 Hashtable 全表 synchronized，CHM 的并发度高得多。

HashMap 线程不安全的底层根源

面试官： 具体会出什么问题？底层的根本原因是什么？

根源是'复合操作非原子 + 可见性缺失'，HashMap 没做任何同步。

比较典型的三个场景：

1. JDK 1.7 扩容死循环：线程 A 在 transfer() 遍历链表 a→b→c，线程 B 同时插入修改了 next 指针；A 把 b 插入新表头后又插入 a，导致 a 的 next 指向 b，形成 a↔b 的环，后续 get 就卡死。
2. 数据覆盖：两个线程同时创建 Node 并赋值 table[index] = newNode，后一个覆盖前一个，元素丢失。1.8 也避免不了。
3. size++ 非原子：size++ 实际是读-改-写三步，并发时最终 size 可能比实际元素数少。

总结就是，HashMap 违反了 JMM 对共享变量操作的原子性、可见性、有序性要求。

Spring Boot 的 IOC 与 AOP

面试官： 解释一下 IOC 和 AOP。

IOC（控制反转）：以前是自己 new Service，现在由 Spring 容器负责创建对象并注入依赖，控制权交给了框架。主要通过 @Component、@Service、@Autowired 实现。

AOP（面向切面编程）：把日志、事务、权限这类横切关注点从业务代码里抽出来，通过动态代理（JDK Proxy / CGLIB）在方法调用的前后插入增强逻辑。常用 @Aspect、@Around、@Before。

一个简单切面示例：

@Aspect
@Component
public class LogAspect {
    @Around("@annotation(Loggable)")
    public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
        long start = System.currentTimeMillis();
        Object result = joinPoint.proceed();
        log.info("Method {} took {} ms", joinPoint.getSignature(), System.currentTimeMillis() - start);
        return result;
    }
}

IOC 的核心价值：解耦与可测试性

面试官： IOC 到底有什么好处？举个实际例子。

最大的好处是解耦和可测试。

假如有个 NoteService 需要文件存储：

// 无 IOC，硬编码
public class NoteService {
    private FileStorageService storage = new LocalFileStorageService();
}

// 有 IOC，接口注入
@Service
public class NoteService {
    @Autowired
    private FileStorageService storage;
}

这样就能灵活替换实现（开发用本地，生产切 OSS），单元测试时可以注入 Mock 对象，而且 Spring 还帮你管理 Bean 的生命周期和作用域。IOC 容器说白了就是个'对象工厂 + 依赖关系图'。

鉴权：Cookie/Session 与 JWT 的取舍

面试官： 项目登录鉴权怎么做的？Cookie、Session 和 JWT 的区别？

区别主要在存储位置、状态管理和扩展性：

我的实践是 JWT + Redis 黑名单：登录返回 JWT（含 userId、exp），退出时将 token 加入 Redis 黑名单（TTL 取剩余有效期），拦截器看到黑名单内的 token 直接拒绝。

常见误区是'JWT 更安全'，其实安全性取决于具体实现：JWT 一旦泄露，在过期前始终有效，而 Session 可以随时让服务端失效。

分布式 ID：Snowflake 算法 64 位结构

面试官： 分布式 ID 生成怎么做的？

我用的是 Twitter Snowflake 算法，64 位长整型：

| 1 位符号位 | 41 位时间戳（毫秒）| 10 位机器 ID | 12 位序列号 |

• 时间戳：可用约 69 年
• 机器 ID：最多 1024 个节点
• 序列号：同一毫秒内支持 4096 个 ID

优点是全局唯一、趋势递增（对数据库索引友好）、单机性能可到 400 万+/s。

简化实现如下：

public synchronized long nextId() {
    long timestamp = System.currentTimeMillis();
    if (timestamp < lastTimestamp)
        throw new RuntimeException("Clock moved backwards");
    if (timestamp == lastTimestamp) {
        sequence = (sequence + 1) & MAX_SEQUENCE;
        if (sequence == 0)
            timestamp = waitNextMillis(lastTimestamp);
    } else {
        sequence = 0;
    }
    lastTimestamp = timestamp;
    return ((timestamp - EPOCH) << TIMESTAMP_SHIFT) | (machineId << MACHINE_ID_SHIFT) | sequence;
}

除此之外，还有美团 Leaf、百度 UidGenerator 等号段模式可选。

多服务并发调用：CompletableFuture 与降级

面试官： 笔记服务里的多服务并发调用，具体遇到过什么问题？

批量导出笔记为 PDF 时，需要并发调用户服务、文件服务、内容服务。串行三次 HTTP 请求接近 600ms，而且一个服务挂了整个流程失败。

解决思路是异步编排 + 超时 + 降级：用 CompletableFuture 并发调用，并让文件服务下载失败时跳过附件，只导出文本。

CompletableFuture<User> userFuture = CompletableFuture.supplyAsync(() -> userService.getUser(userId));
CompletableFuture<Content> contentFuture = CompletableFuture.supplyAsync(() -> contentService.getContent(noteId));
// 合并结果
User user = userFuture.join();
Content content = contentFuture.join();

核心就是并发编排、超时控制和失败时的兜底策略。

Python GIL：为什么多线程不能利用多核

面试官： Python 是单进程单线程的？为什么？

准确说 Python 支持多线程，但 CPython 解释器有 GIL（全局解释器锁），同一时刻只有一个线程能执行字节码。原因是 CPython 用引用计数管理内存，多线程同时修改引用计数会导致崩溃，所以引入了这把大锁。

影响是：CPU 密集型任务用多线程反而不如单线程，因为线程切换和争锁；但 IO 密集型任务在线程阻塞 IO 时会释放 GIL，其他线程可以跑，仍有并发收益。

应对方案：CPU 密集型用 multiprocessing 多进程，或者换成 PyPy/Jython 这类无 GIL 的解释器。

HTTP 异常处理：该捕获哪些异常

面试官： HTTP 请求失败需要处理哪些异常？

以 RestTemplate 为例，我会区分这几种：

示例代码：

try {
    ResponseEntity<String> response = restTemplate.getForEntity(url, String.class);
} catch (HttpClientErrorException e) {
    if (e.getStatusCode() == HttpStatus.UNAUTHORIZED) {
        // 重新登录或刷新 token
    }
} catch (ResourceAccessException e) {
    log.error("Network error", e);
    throw new BusinessException("服务暂时不可用");
}

实践中还可以引入 RetryTemplate 做自动重试，配合 Hystrix 或 Sentinel 实现熔断降级。

小结

这场面试的追问基本都落在这几点：深挖底层机制（比如 HashMap 死循环的 JMM 根源）、追问方案之间的权衡（JWT vs Session，红黑树 vs AVL），以及考察异常场景下的系统健壮性（HTTP 异常分类、并发降级）。平时看源码、理解设计动机，回答时带上场景和边界，会比单纯背结论更有说服力。