
---

**1. HashMap 在 JDK 1.7 和 1.8 中实现上有什么关键区别？为什么说 HashMap 是线程不安全的？**

**参考答案：**

先从数据结构上说，1.7 是数组 + 链表，1.8 开始引入了红黑树。当链表长度超过阈值（默认 8）且数组长度不小于 64 时，链表会转成红黑树，防止在哈希冲突严重时退化成 O(n) 的查询。

再一个很重要的改动是头插法和尾插法。1.7 在扩容时转移链表用的是头插法，多线程环境下并发扩容可能形成循环链表，导致 CPU 100%。1.8 改成了尾插法，避免了循环链表的问题，但这不代表 HashMap 就变成线程安全了。

线程不安全主要体现在：
- 多线程 put 的时候，如果发生了扩容，数据可能会丢失。比如两个线程同时拿到同一个 oldTable，各自迁移后一个覆盖另一个的结果。
- size 字段不是原子的，多线程 put 可能导致计数偏小，甚至出现同一位置的值被覆盖。
- 在 1.8 中，虽然规避了死循环，但如果两个线程同时操作同一个链表/树节点，依然可能出现节点丢失或 next 指针错乱。

所以我一般会在需要并发的场景直接换 ConcurrentHashMap，或者在局部确认无竞争的情况下用 HashMap。

---

**2. 用 Java 实现一个线程安全的高并发计数器，你有哪些方案？各自适用什么场景？**

**参考答案：**

这个问题其实不限定具体写法，重点考察对不同并发工具的理解。我通常会对比几种方案：

- **synchronized 方法/代码块**：最简单，直接在递增方法上加锁。优点是写起来简单，问题少；缺点是在竞争非常激烈时性能一般，现在 JVM 对 synchronized 优化已经做得很好，比如偏向锁、轻量级锁，但如果只是简单计数，锁的粒度还是有点大。

- **AtomicInteger / LongAdder**：如果只是计数，优先考虑这个。AtomicInteger 基于 CAS，无锁，线程竞争不是很激烈的时候性能非常好。但竞争一激烈，CAS 空转浪费 CPU。这时候 LongAdder 就更合适，它内部用分段累加的思想，将一个变量拆成多个 Cell，最后求和，分散竞争，高并发下吞吐量明显高于 AtomicInteger。代价是统计时调用 sum() 会有一定开销，而且不是强一致性的，适合实时性要求不高的统计。

- **volatile + 锁**：单纯 volatile 只保证可见性，不保证原子性，不能直接用 volatile 做 i++。如果配合锁，还不如直接用原子类。

- **juc 里的其他工具**：比如可以用 ReentrantLock 做的显式锁，但这个和 synchronized 类似，没什么必要为计数单独用。

实际选型时，如果只是并发不太高的场景，AtomicInteger 足够。如果是超高并发、接受最终一致性的计数（比如统计 QPS），LongAdder 会更合适。如果在业务方法里已经有一把大锁，那直接在锁保护的代码块里用普通 int 计数也无妨。

---

**3. 请你说说 @Transactional 在哪些情况下会失效？**

**参考答案：**

这个问题挺常见的，失效场景大致可以归为几类：

- **同类方法自调用**：这是最经典的一个。Spring 的事务是通过 AOP 代理实现的，如果在一个不带 @Transactional 的方法里，直接通过 this.xxx() 调用同一个类中带有 @Transactional 的方法，调用会绕开代理对象，导致事务不生效。解决办法可以是注入自身代理（比如用 @Autowired 注入自己），或者把被调用的方法抽到另一个 Bean 里，再或者开启 AspectJ 的编译时/加载时织入。

- **方法不是 public 的**：默认情况下 Spring 使用 JDK 动态代理或 CGLIB 代理，基于代理的实现要求被代理方法是 public。如果方法修饰符是 protected、default 或者 private，代理对象的方法不会被增强，事务自然也就失效了。不过如果是 AspectJ 模式则没有这个限制。

- **异常被“吞掉”了**：@Transactional 默认回滚的是 RuntimeException 和 Error，受检异常（checked exception）不会触发回滚，除非通过 rollbackFor 明确指定。如果代码里 catch 住了异常，既没往外抛也没手动设置回滚，事务就不会回滚，反而会正常提交，这种坑在业务代码里经常踩。

- **数据库引擎不支持事务**：比如用了 MyISAM 表，再怎么说事务也没用。

- **多线程环境**：事务是绑定在线程上的（通过 ThreadLocal 传递），如果在一个事务方法里开启新线程去执行数据库操作，新线程无法共享原事务上下文，自然不会参与到当前事务中。

- **传播行为设置不当**：比如设置了 PROPAGATION_NOT_SUPPORTED 会挂起当前事务，或者 PROPAGATION_NEVER 直接报异常。还有 PROPAGATION_REQUIRES_NEW 会让内层方法独立开新事务，外层失败不影响内层提交，这严格说不算“失效”，但容易造成误解。

好的，再补充一些中级 Java 面试里经常被问到的题目，依然尽量用真实交流的方式来回答。

---

**4. ConcurrentHashMap 在 JDK 1.8 是怎么保证线程安全的？和 Hashtable 比好在哪？**

**参考答案：**

1.7 的 ConcurrentHashMap 是用分段锁来做的，内部有一个 Segment 数组，每个 Segment 继承 ReentrantLock，锁的是整个段。默认分 16 段，最大并发也就是 16。而 1.8 可以说脱胎换骨，改成了 **CAS + synchronized** 来实现，锁的粒度细到了单个数组槽位上。

具体来说，put 的时候会先通过一次 CAS 去尝试把值塞到一个空桶里，如果失败或者桶里已经有元素了，就会用 synchronized 锁住桶中的头节点，然后在这个链表或者红黑树上做插入或更新。只有锁住了这个桶，别的线程就不能同时操作这个桶，但完全可以去操作其他桶。这样一来，并发度就远高于 1.7，理论上最多可以等于数组的长度。

扩容上也比 1.7 聪明很多，1.8 支持多线程协助扩容，每个线程负责一部分索引区间的数据迁移，没有互相阻塞，整体迁移效率更高。

跟 Hashtable 比起来，Hashtable 基本就是所有方法一把大锁，整个表锁住，同一时间只能有一个线程干活，其他全部排队。ConcurrentHashMap 的细粒度锁直接让并发场景下的吞吐量高了不止一个数量级。另外，ConcurrentHashMap 的迭代器是弱一致性的，不会在迭代时因为其他线程修改而抛出 `ConcurrentModificationException`，而 Hashtable 迭代器会快速失败。但需要注意，ConcurrentHashMap 的 key 和 value 都不能为 null，这点和 Hashtable 一样，和 HashMap 不一样。

---

**5. 谈谈 Java 内存模型和 volatile 关键字的作用及原理。**

**参考答案：**

Java 内存模型，说简单点就是定义了一套规范，来约束 JVM 在多线程环境下，一个线程对共享变量的写何时能被另一个线程看见，以及什么情况下会重排序。

我们常说每个线程有自己的工作内存，变量实际上放在主内存里，线程操作时拷贝一份到工作内存，改完再写回去。这个模型里如果不加控制，就会出现可见性问题和重排序问题。

volatile 专门解决这两个问题。

- **可见性**：一旦一个变量被 volatile 修饰，线程在写这个变量后，JVM 会强制把工作内存的改动立刻刷到主内存，并且让其他线程工作内存中的这个变量缓存失效，迫使它们重新从主内存读。这样每个线程读到的就一定是最新的值。

- **禁止指令重排序**：JVM 为了性能会在单线程语义不变的前提下进行指令重排序，但是多线程就可能出问题。volatile 通过插入内存屏障来阻止它前后的指令重新排布，保证一个经典的“happens-before”关系——对 volatile 变量的写一定先于后续对这个变量的读。

典型应用就是双重检查锁单例里的 `instance` 变量，还有多线程下的状态标记位。比如一个线程在跑循环，另一个线程通过修改 volatile 标志来优雅停掉它。

但 volatile 解决不了原子性，像 `i++` 这种复合操作依然需要 synchronized 或者 AtomicInteger，因为它只是保证单次读写的顺序和可见性。

---

**6. synchronized 的锁升级过程是怎样的？**

**参考答案：**

在早期 JDK 里，synchronized 就是一上来直接拿操作系统的互斥量，非常重。后来做了很多优化，引入了偏向锁、轻量级锁、自旋锁这些机制，变成了一个逐步升级的过程，而且一般不可降级。

锁信息是记录在对象头里的 Mark Word 里的。

- **偏向锁**：当一个线程第一次获取锁时，JVM 会把对象头里的线程 ID 设为当前线程，以后这个线程再进出同步块时，只需要检查 Mark Word 里是不是自己的 ID，如果是就直接通过，都不用 CAS，几乎零开销。这特别适合那种“一个线程反复加锁”的场景，比如 Vector 或 StringBuffer 里循环调用同步方法。一旦另一个线程也来尝试拿这个锁，偏向锁就会被撤销，膨胀为轻量级锁。

- **轻量级锁**：这个阶段会在线程的栈帧里创建一个锁记录，然后通过 CAS 把对象头里的 Mark Word 替换成指向锁记录的指针。如果替换成功，线程就持有轻量级锁了。如果 CAS 失败，说明已经有别的线程占用了锁，当前线程会先自旋一会儿，也就是做几次空循环去尝试拿锁，希望对方很快就释放。如果在自旋期间拿到了，就还是轻量级锁；如果自旋超过一定次数（可以自适应），就会认为是比较重的竞争，升级成重量级锁。

- **重量级锁**：这时就回到传统的操作系统互斥量，没能拿到锁的线程会直接挂起，进入 BLOCKED 状态，等前一个线程释放锁后再被唤醒，完全由操作系统调度。这一步上下文切换开销大，但适合长时间持有锁的场景。

这个升级过程让 synchronized 在大多数实际竞争不强或者只是“一两个线程偶尔碰一下”的场景下，性能已经接近 Lock 了。

---

**7. 线程池的核心参数以及常见拒绝策略，怎么合理配置？**

**参考答案：**

线程池我平时用的都是 `ThreadPoolExecutor`，核心参数就是那七个，不过最关键的四个是：

- **corePoolSize**：核心线程数，即使闲着也不会被回收，除非设置了 `allowCoreThreadTimeOut`。
- **maximumPoolSize**：最大线程数，当队列满后能临时扩出来的线程数量。
- **keepAliveTime**：非核心线程空闲多久后被回收。
- **workQueue**：工作队列，常见的有 `LinkedBlockingQueue`、`ArrayBlockingQueue`、`SynchronousQueue`。

工作流程这样：任务一来，先看核心线程满了没有，没满就建核心线程；满了就扔进工作队列；如果工作队列是有界的并且也满了，而且当前线程数还小于最大线程数，就创建非核心线程来干；如果连最大线程数都达到了，就执行拒绝策略。

常见的拒绝策略：

- **AbortPolicy**：直接抛 `RejectedExecutionException`，这也是默认策略，比较直接。
- **CallerRunsPolicy**：把任务交回给提交它的线程自己跑，能减少新任务提交速度，起到一种“缓冲”作用。
- **DiscardPolicy**：直接默默丢掉任务，啥异常也没有，这个要非常小心。
- **DiscardOldestPolicy**：丢弃队列里最老的那个任务，然后重新尝试提交当前任务。

配置的话，一般会分开看是 CPU 密集型还是 I/O 密集型。CPU 密集型尽量不搞太多线程避免上下文切换，`核心数 + 1` 比较常见。I/O 密集型因为大部分时间线程都在等待，可以设置大一些，比如 `2 * CPU核数`，但最好还是根据实际测试结果调优。另外，一定要小心无界队列导致的 OOM，生产上一般会选有界队列，然后配合合适的拒绝策略。

---

**8. Spring Bean 的生命周期是怎样的？哪些地方可以介入？**

**参考答案：**

Spring Bean 的生命周期其实涉及很多回调，但梳理起来主要分几个阶段：

1. **实例化**：容器通过反射创建 Bean 的实例，调用构造方法。
2. **属性赋值**：把通过 `@Value`、`@Autowired` 或是 XML 里配置的 property 值注入进去，还包括各种 Aware 接口回调，比如 `BeanNameAware`、`BeanFactoryAware`、`ApplicationContextAware`。
3. **前置处理**：`BeanPostProcessor` 的 `postProcessBeforeInitialization` 被调用，这个接口非常强大，很多框架都用它来做代理包装。
4. **初始化**：如果 Bean 实现了 `InitializingBean`，就调 `afterPropertiesSet()`；如果配置了 `init-method` 或者加了 `@PostConstruct` 注解，也会在这里执行。三者顺序是：`@PostConstruct` 标记的方法最先，然后是 `afterPropertiesSet`，最后是 `init-method`。
5. **后置处理**：`BeanPostProcessor` 的 `postProcessAfterInitialization` 调用，这里经常被用来做 AOP 代理的生成，比如返回一个 CGLIB 或 JDK 动态代理对象替换原始 Bean。
6. **就绪**：Bean 正式可用，被放回容器里。
7. **销毁**：容器关闭时，如果实现 `DisposableBean` 则调 `destroy()`，如果有 `@PreDestroy` 注解或配置的 `destroy-method` 也会依次执行。

我在项目里最常用的是 `@PostConstruct` 做一些初始化后需要额外处理的事情，比如从配置中心拉配置、预热缓存等。`@PreDestroy` 用来做一些资源释放，比如关闭内部线程池。另外如果要对所有 Bean 做统一行为，比如对加了特定注解的方法做切面，就可以写一个 `BeanPostProcessor`。

---

**9. 手写一个线程安全的懒汉式单例，并解释双重检查锁为何需要 volatile？**

**参考答案：**

代码一般是这样：

```java
public class Singleton {
    private static volatile Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {                // 第一次检查
            synchronized (Singleton.class) {
                if (instance == null) {        // 第二次检查
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}
```

这个设计里，外层 `if` 是为了性能，避免每次调用都去抢锁；内层 `if` 才是真正保证只创建一个实例的。

那么为什么 `instance` 必须用 `volatile`？因为在 JVM 里 `new Singleton()` 并不是一个原子操作，它大致可以拆成三步：

1. 给对象分配内存空间
2. 调用构造器，初始化对象内部属性
3. 将 `instance` 引用指向分配好的内存地址

如果编译器或 CPU 为了优化，把第 2 步和第 3 步重排序了，那么 `instance` 就可能先指向了一个还没初始化完成的内存区域。假设线程 A 走到了这个重排序后的“先赋值、后初始化”流程，当它刚把引用赋完但还没执行初始化时，线程 B 刚好来读外层 `if (instance == null)`，发现不是 null，就直接拿走了这个没构造好的对象去用，导致业务数据错乱，甚至 NPE。

`volatile` 通过内存屏障禁止了这种重排序，保证了写操作会完全完成才对其他线程可见，而且读取也能看到最新的完整状态，从而避免了这一问题。

1. HashMap 在 JDK 1.7 和 1.8 中实现上有什么关键区别？为什么说 HashMap 是线程不安全的？

XXX公司面试题001

后端

JDK1.7和1.8的HashMap实现差异：1.7采用数组+链表结构，1.8引入红黑树优化查询性能。1.7头插法扩容存在线程安全问题，1.8改用尾插法但仍非线程安全。ConcurrentHashMap通过CAS+synchronized实现细粒度锁，比Hashtable性能更高。volatile保证可见性和禁止指令重排序，synchronized锁升级机制优化并发性能。线程池配置需区分CPU密集型和I/O密集型任务，合理设置核心参数和拒绝策略。Spring Bean生命周期包含实例化、属性注入、初始化等阶段，可通过回调接口介入。

数据迁移

数据结构

数据库

编译器

容器

Java

2026年中大促 | AI 领航 智绘未来

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

JDK1.7和1.8的HashMap实现差异：1.7采用数组+链表结构，1.8引入红黑树优化查询性能。1.7头插法扩容存在线程安全问题，1.8改用尾插法但仍非线程安全。ConcurrentHashMap通过CAS+synchronized实现细粒度锁，比Hashtable性能更高。volatile保证可见性和禁止指令重...

XXX公司面试题001-腾讯云开发者社区-腾讯云

XXX公司面试题001

XXX公司面试题001

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐