有一只柴犬的专栏

多线程固然可以提升系统的吞吐量，也可以最大化利用系统资源，提升相应速度。但同时也提高了编程的复杂性，也提升了程序调试的门槛。今天就来汇总一些常见的并发编程中的问题。

“分而治之”一直是一个非常有效的处理大量数据的方法。著名的MapReduce也是采取了分而治之的思想。。简单地说，就是如果你要处理 1000 个数据，但是你并不具备处理 1000个数据的能力，那么你可以只处理其中的 10 个，然后分阶段处理 100 次，将 100 次的结进行合成，就是最终想要的对原始 1000 个数据的处理结果。而这就是Fork Join的基本思想。

Future 模式是多线程开发中非常常见的一种设计模式，它的核心思想是异步调用。当我们需要调用一个函数方法时，如果这个函数执行得很慢，那么我们就要进行等待。但有时候，我们可能并不急着要结果。因此，我们可以让被调者立即返回，让它在后台慢慢处理这个请求。对于调用者来说，则可以先处理一些其他任务，在真正需要数据的场合再去尝试获得需要的数据。

一般提到多线程并发总是要说资源竞争，线程安全。而通常保证线程安全的其中一种方式便是控制资源的访问，也就是加锁。其实还有另一种方式，那么便是增加资源来保证所有对象不竞争少数资源。比如，有100个人需要填写信息表，如果只有一只笔，那么要么变成串行，一个一个填写，要么就是我写一半你写一半。那么如果准备100只笔，100个人每个人都有一只笔能够填写信息表，那么就不会出现竞争的情况，也就能顺利的保证信息表的填写。这支笔也就是我们今天要说的ThreadLocal。

学习JUC，就不得不提生产者消费者。生产者消费者模型是一种经典的多线程模型，用于解决生产者和消费者之间的数据交换问题。在生产者消费者模型中，生产者生产数据放入共享的缓冲区中，消费者从缓冲区中取出数据进行消费。在这个过程中，生产者和消费者之间需要保持同步，以避免数据出现错误或重复。今天我们就来说说生产者消费者模型，以及JUC中如何解决该模型的同步问题。

我们继续前面的《【JUC基础】12.线程池（一）》。

我们知道多线程的使用，是为了最大限度发挥现代多核处理器的计算能力，提高系统的吞吐量和性能。但是如果不加以控制和管理，随意使用多线程，对系统性能反而会有不利的影响。线程数量和系统CPU资源是息息相关的，随意使用甚至可能会耗尽系统CPU资源和内存资源。

我们直到ArrayList，HashMap等是线程不安全的容器。但是我们通常会频繁的在JUC中使用集合类，那么应该如何确保线程安全？

Atomic英译为原子的。原子结构通常称为不可分割的最小单位。而在JUC中，java.util.concurrent.atomic 包是 Java 并发库中的一个包，提供了原子操作的支持。它包含了一些原子类，用于在多线程环境下进行线程安全的原子操作。使用原子类可以避免使用锁和同步机制，从而减少了线程竞争和死锁的风险，并提高了多线程程序的性能和可伸缩性。

LockSupport是一个线程阻塞工具，可以在线程任意位置让线程阻塞。线程操作阻塞的方式其实还有Thread.suspend()和Object.wait()。而LockSupport与suspend()相比，弥补了由于resume()方法而导致线程被挂起（类似死锁）的问题，也弥补了wait()需要先获得某个对象锁的问题，也不会抛出InterruptedException异常。

JUC包中包含了三个非常实用的工具类：CountDownLatch（倒计数器），CyclicBarrier（循环栅栏），Semaphore（信号量）。

wait()，notify()虚假唤醒

前面两篇中分别讲了Synchronized和ReentrantLock。两种方式都能实现同步锁，且也都能解决多线程的并发问题。那么这两个有什么区别呢？ 这个也是一个高频的面经题。

java.util.concurrent.locks为锁定和等待条件提供一个框架的接口和类，说白了就是锁所在的包。

程序员经常听到“并发锁”这个名词，而且实际项目中也确实避免不了要加锁。那么什么是锁？锁的是什么？今天文章从8个有意思的案例，彻底弄清这两个问题。

juc思维导图，用于JUC内容学习

前段时间，有朋友跟我说，能否写一些关于JUC的教程文章。本来呢，JUC也有在我的专栏计划之内，只是一直都还没空轮到他，那么既然有这样的一个契机，那就把JUC计划提前吧。那么今天就重点来初步认识一下什么是JUC，以及一些基本的JUC相关基础知识。