登录
首页 >  文章 >  java教程

Java并发编程面试题及核心考点解析

时间:2026-01-05 20:36:42 216浏览 收藏

文章小白一枚,正在不断学习积累知识,现将学习到的知识记录一下,也是将我的所得分享给大家!而今天这篇文章《Java并发编程高频面试题及核心考点》带大家来了解一下##content_title##,希望对大家的知识积累有所帮助,从而弥补自己的不足,助力实战开发!


面试考察的是真实场景经验而非背诵,核心能力包括:线程安全三要素(原子性、可见性、有序性)的落地与修复;阻塞队列相比wait/notify的优势及JUC实践;线程池显式构造的必要性与参数调优;ThreadLocal在线程池中未清理导致的数据错乱风险及规避方案。

Java并发编程中常见面试问题有哪些_核心知识点汇总

Java并发编程面试问题不是考背诵,而是考你有没有在真实场景里踩过坑、调过线程 dump、修过时序 bug。下面这些是高频真题背后真正要考察的能力点,按实战逻辑归类整理。

线程安全三要素:原子性、可见性、有序性怎么落地?

面试官问“怎么保证线程安全”,答 synchronized 或 Lock 是及格;答清楚这三点在代码中如何被破坏、又如何被修复,才算过关。

  • 原子性:比如 i++ 看似一行,实为读-改-写三步,多线程下会丢失更新。用 AtomicInteger.incrementAndGet() 或加锁才能真正原子
  • 可见性:一个线程改了 flag = true,另一个线程可能永远看不到。必须用 volatilesynchronizedLock,否则 JVM 可能从本地缓存读旧值
  • 有序性:JVM 和 CPU 可能重排序,比如构造函数里先赋值字段再发布 this 引用,导致其他线程看到半初始化对象。靠 volatile 写、synchronized 块或 final 字段触发 Happens-Before

阻塞队列 vs. wait/notify:生产者-消费者该选哪个?

手写 wait()/notify() 实现阻塞队列是经典陷阱题——它容易漏唤醒、假唤醒、条件竞争,且无法指定超时。而 JUC 的 BlockingQueue(如 ArrayBlockingQueueLinkedBlockingQueue)已封装所有边界逻辑。

  • put() / take() 自动处理阻塞和唤醒,无需手动管理 monitor 锁
  • offer(e, timeout, unit)poll(timeout, unit) 支持优雅降级,避免无限等待
  • 注意 LinkedBlockingQueue 默认容量是 Integer.MAX_VALUE,若生产过快且消费阻塞,可能 OOM
ExecutorService executor = Executors.newFixedThreadPool(2);
BlockingQueue<String> queue = new ArrayBlockingQueue<>(100);
executor.submit(() -> { // 生产者
    for (int i = 0; i < 1000; i++) {
        try {
            queue.put("msg-" + i); // 满时自动阻塞
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            break;
        }
    }
});
executor.submit(() -> { // 消费者
    while (true) {
        try {
            String msg = queue.take(); // 空时自动阻塞
            System.out.println(msg);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            break;
        }
    }
});

线程池创建:为什么禁止直接用 Executors 工厂方法?

因为它们隐藏了关键参数,极易引发线上事故。比如 newFixedThreadPool(n) 底层用的是无界 LinkedBlockingQueue,任务积压会导致内存溢出;newCachedThreadPool() 允许无限创建线程,CPU 扛不住。

  • 正确做法是显式构造 ThreadPoolExecutor,控制 corePoolSizemaximumPoolSizeworkQueue(建议有界)、RejectedExecutionHandler
  • CPU 密集型任务:线程数 ≈ CPU 核数;IO 密集型可适当放大(如核数 × 2),但需压测验证
  • 务必设置 ThreadFactory 命名线程,否则线程 dump 里全是 pool-1-thread-1,无法定位归属

ThreadLocal 在线程池中不清理会导致什么?

这是高危雷区。线程池复用线程,而 ThreadLocal 的值会随线程生命周期延续。如果业务代码往 ThreadLocal 存了数据库连接、用户上下文、事务 ID,下一个任务拿到的可能是上一个请求残留的数据——轻则数据错乱,重则越权访问。

  • 每次使用后必须调用 threadLocal.remove(),尤其在 filter / interceptor / finally 块中
  • 不要依赖 ThreadLocalinitialValue() 自动初始化,它只在首次 get 时触发,复用线程不会再次调用
  • 更安全的替代方案:用 MDC(logback)做日志追踪,或把上下文作为参数显式传递

并发编程最难的从来不是 API 调用,而是理解「谁在什么时候看到了什么值」。很多 bug 不是代码写错了,而是对内存模型、调度时机、锁释放顺序的直觉出了偏差。多看 thread dump,少信“应该没问题”。

今天带大家了解了的相关知识,希望对你有所帮助;关于文章的技术知识我们会一点点深入介绍,欢迎大家关注golang学习网公众号,一起学习编程~

前往漫画官网入口并下载 ➜
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>