进程与线程通信方式详解：从IPC到线程池与并发安全

1. 写在前面：为什么搞懂进程和线程通信，是所有开发者的必修课

先抛出这次项目的主题核心：进程与线程的通信方式。这两个词对于写代码的人来说，几乎天天碰面，尤其是后端、客户端、中间件开发，以及运维排查问题的时候，绕不开这两个概念。

很多初学者容易把“进程”和“线程”混在一起，或者只记得“线程是轻量级进程”这种概念性描述，一遇到实际场景就蒙了。比如：

• 线程池的阻塞队列到底选有界还是无界？
• 线程池的submit和execute有什么区别？
• 进程间通信为什么有那么多方式，管道、消息队列、共享内存到底该怎么选？
• Java里为什么说String、Integer这些类是线程安全的，而ArrayList不是？
• 系统里出现了疑似异常进程（比如kswapd、rundll32），怎么判断是正常系统进程还是需要关注的进程？

这些问题本质上都指向同一个底层知识体系：进程与线程之间，到底是怎么协作、怎么传递数据、怎么同步状态的。

这篇文章我会把“进程与线程通信方式”这件事拆开揉碎，从最基础的进程与线程关系讲起，再到具体的IPC方式、线程间同步与通信手段，结合线程池、死锁、线程安全、守护线程这些高频面试和实战话题，给出完整的梳理。适合刚接触并发编程的开发者，也适合工作两三年想系统补一遍底层知识的人，运维和测试同学同样能从中找到排查问题的思路。

2. 进程与线程的本质差异：先搞清楚谁在通信、为什么需要通信

2.1 进程是资源分配单位，线程是调度单位

这个话题必须从操作系统层面说起。进程是操作系统进行资源分配的基本单位，每个进程有自己独立的地址空间、文件描述符表、信号处理器、环境变量等。线程是CPU调度的基本单位，线程自己几乎没有独立的资源，它共享所属进程的地址空间和大部分资源。

你可以这样理解：进程就像一家独立的公司，有自己的办公室、财务、法务、办公设备；线程就像公司里的员工，大家在同一间办公室办公，共用打印机、会议室、饮水机。公司之间的合作需要签合同、走正式流程，而公司内部的员工之间说话、传文件就方便得多。

这个本质差异直接决定了通信方式的不同：

• 因为进程间地址空间互不可见，所以要通信必须借助内核提供的机制，比如管道、消息队列、共享内存、Socket等，这就是进程间通信（IPC）。
• 因为线程共享进程的地址空间，所以线程间通信天然可以通过共享变量来实现，但随之而来的问题是并发访问的同步和互斥，不然就会出现数据错乱。

2.2 为什么不能用一个方案通吃所有场景

很多人会问：既然程序内部能用共享内存，为什么还要搞出那么多进程间的通信方式？

我的理解是这样的：隔离和通信永远是矛盾的两面。进程隔离保证了稳定性，一个进程崩溃不会直接拖垮另一个进程，这是操作系统稳定性的根基。但如果完全隔离，不同程序就无法协作，所以操作系统必须提供受控的通信通道。这些通道各自有不同的性能、复杂度、适用场景，没有绝对的银弹。

举个例子，同一个系统里，nginx和php-fpm之间用Socket通信，而php-fpm内部的多个worker进程之间可能要操作共享内存来统计请求数。同样是数据交换，跨进程和跨线程的路径完全不同。

2.3 父子进程、守护进程这些概念的通信含义

热词里提到了父子进程和守护进程。父子进程本质上是通过fork出来的，子进程复制了父进程的地址空间，但它们是两个独立进程。父子进程之间常用的通信方式是管道——这是最经典的一种IPC，shell命令里的ls | grep就是管道通信。

守护进程（daemon）是长期在后台运行、没有控制终端的进程，它一般不会主动和用户交互，但会通过日志、信号、Socket等方式对外通信。比如nginx的master进程是守护进程，worker进程接受它的调度，通过信号和共享内存通信。你写Java时用的Thread.setDaemon(true)标记的守护线程，也遵循同样的逻辑——守护线程服务于非守护线程，当所有非守护线程结束时，守护线程自动终止。

这里有一个经常被忽略的点：很多人以为守护线程“不重要”，其实它恰恰是很多后台任务的核心载体，比如JVM里的GC线程就是守护线程，如果所有工作线程都结束了，GC线程也没必要存活了。理解这个模型，对排查“为什么程序退出了但进程还在”这类问题很有帮助。

3. 进程间通信（IPC）的核心方式：管道、消息队列、共享内存、Socket等

3.1 管道：最简单但限制也最明显的通信方式

管道是Unix系统最古老的IPC方式之一，核心思路是让一个进程的输出直接变成另一个进程的输入，数据在内核缓冲区里流动。

管道分两类：匿名管道和命名管道。

匿名管道只能在有亲缘关系的进程之间使用（典型的就是父子进程），它没有名字，生命周期随进程结束而结束。用shell命令时最常见的例子就是ps -ef | grep java，左边进程的标准输出接到右边进程的标准输入，中间就是一根匿名管道。

命名管道（FIFO）则可以在任意进程之间通信，它会在文件系统里创建一个特殊的管道文件，两个进程通过打开同一个文件路径来通信。举个例子，在Linux终端里：

bash复制# 终端A创建一个命名管道
mkfifo /tmp/myfifo

# 终端A阻塞等待写入
echo "hello" > /tmp/myfifo

# 终端B读取
cat /tmp/myfifo

这段流程演示了命名管道的核心特性：它是单向的、面向字节流的，并且写入端和读取端必须同时存在才能完成数据传输，否则写入会阻塞。

管道的优点很明显：实现简单，系统调用开销小，适合小数据量的进程间通信。缺点也很突出：半双工（数据只能单向流动，如果要双向通信需要两根管道），数据无边界（读端不知道一次写入的数据从哪里结束），并且不适合大数据量传输。

3.2 消息队列：带边界的可靠通信

消息队列和管道的本质区别在于，它传递的是“有格式的消息”而不是“裸的字节流”。每个消息有类型和长度，接收方可以按类型读取，不必遵从先进先出的顺序。

实际开发中，消息队列分两大类：POSIX消息队列和System V消息队列（不同系统实现细节有差异，但思路一致）。

消息队列的优点包括：

• 消息有边界，读写双方不需要自己设计协议来切分数据流
• 支持按消息类型读取，可以实现优先级处理
• 生命周期由内核管理，进程退出后队列里的消息不会立刻消失

缺点方面：

• 消息大小有限制，不适合传输大文件或大数据块
• 需要处理“消息满”和“消息空”的阻塞语义
• 相比共享内存，性能要差一些，因为每次收发消息都要经过内核拷贝

如果是Java开发者，可以类比理解Java里的BlockingQueue——虽然一个是进程间、一个是线程间，但“队列”这个模型是一致的，都是解耦生产者和消费者。

值得提醒的是，实际业务系统里很少有人直接操作System V消息队列了，因为轻量级消息中间件（比如Redis的List结构、RabbitMQ等）提供了更强大的功能。但作为底层原理，理解消息队列的机制对排查问题仍然有帮助。

3.3 共享内存：性能天花板，但同步要自己搞定

共享内存是公认的效率最高的IPC方式，因为它直接把一块物理内存映射到多个进程的虚拟地址空间，数据不需要在内核和用户态之间来回拷贝，进程A写入的数据，进程B立刻就能看到。

打个比方，管道像两个人用一根管子传纸条，消息队列像通过邮局寄信，而共享内存是两个人共用一个写字台，想写什么直接写在桌上，对方抬眼就能看到。

但共享内存有个核心难点：同步问题。当多个进程同时读写这块内存时，需要配合互斥锁或信号量来防止数据竞争。如果只追求性能、忽略同步，轻则数据错乱，重则直接导致程序崩溃。

使用共享内存的基本步骤（以Linux C接口为例）：

c复制// 1. 创建或获取共享内存段
int shmid = shmget(IPC_PRIVATE, 4096, IPC_CREAT | 0666);

// 2. 将共享内存段附加到进程地址空间
void *ptr = shmat(shmid, NULL, 0);

// 3. 直接通过ptr读写共享数据
sprintf(ptr, "hello from process");

// 4. 操作完成后分离
shmdt(ptr);

// 5. 删除共享内存段
shmctl(shmid, IPC_RMID, NULL);

Java里对应的是MappedByteBuffer或FileChannel.map做内存映射文件，底层思路同源。RocketMQ的消费队列文件就是典型的共享内存映射设计，所以它能在保证高性能的同时处理海量消息。

3.4 信号、信号量和文件锁：少量信息的通知与互斥

信号（signal）是异步事件通知机制，主要用于通知进程“发生了某事”，比如Ctrl+C发送SIGINT终止进程、kill -9发送SIGKILL强杀进程、kill -HUP通知进程重载配置（nginx常用的reload方式就是通过信号实现的）。

信号的特点是开销极小、实时性好，但能传递的信息极其有限，通常只作为“通知”而不是“数据传输”手段。

信号量（semaphore）不用于传输数据，而是用于同步和互斥。它本质上是一个计数器，进程通过P操作（wait）和V操作（signal）来控制对共享资源的访问。经典的生产者-消费者问题，就可以用信号量完美解决。

文件锁则是在多进程访问同一文件时，通过加锁来避免并发写入导致的数据损坏。比如很多应用只允许运行一个实例，就是通过给pid文件加锁来实现的。

3.5 Socket通信：跨主机通信的统一方案

如果你需要两个进程在不同机器上通信，前面的方式全部失效，因为它们都是基于本机的内核机制。这时候要用Socket。

Socket不仅支持本机进程间通信，还支持跨网络通信，这也是目前分布式系统最主流的通信方式。Java里的RMI、Dubbo、gRPC，底层走的都是Socket。

有意思的是，即使通信双方在同一台机器上，Socket的效率和共享内存相比差距很大，但它的优势是理论上是“无边界”的——从本机扩展到集群，代码模型几乎不用变。这也是为什么很多中间件选择用Socket而不是共享内存做跨进程通信的原因。

3.6 进程通信方式怎么选：一张表讲明白

我个人的经验是：如果只是在单机内部做高性能数据交换，共享内存是最优解；如果追求开发效率和代码可维护性，优先考虑Socket或消息队列；如果只是简单的父子进程通知，管道和信号足够。

4. 线程间通信与同步：共享内存的并发难题

4.1 线程间天然共享地址空间，通信靠共享变量

线程间的通信比进程间简单得多，因为同一进程的线程共享堆内存、静态变量、文件描述符等资源。一个线程修改了共享对象的值，另一个线程在同一时刻读到的就是这个修改后的值（在保证可见性的前提下）。

但恰恰是因为“太容易共享”，引发了并发编程的核心难题：

• 竞态条件：多个线程同时读写同一个变量，最终的结果取决于线程执行的时序
• 内存可见性：一个线程修改了变量，另一个线程不一定能立即看到（CPU缓存和指令重排引起）
• 死锁：多个线程互相持有对方需要的锁，谁也无法继续执行

4.2 Java里的线程间通信经典手段

Java作为使用最广泛的并发编程语言之一，提供了非常丰富的线程通信机制，这里挑几个核心的展开说。

synchronized + wait/notify

这是最底层的线程通信方式。synchronized保证同一时刻只有一个线程持有某个对象的内置锁，wait让当前线程释放锁并进入等待状态，notify唤醒同一个锁上等待的某个线程。

一个典型的例子是生产者消费者模型：

java复制class SharedQueue {
    private final LinkedList<Integer> queue = new LinkedList<>();
    private final int capacity = 10;

    public synchronized void produce(int value) throws InterruptedException {
        while (queue.size() == capacity) {
            wait(); // 队列满了，生产者等待
        }
        queue.add(value);
        notifyAll(); // 唤醒可能等待的消费者
    }

    public synchronized int consume() throws InterruptedException {
        while (queue.isEmpty()) {
            wait(); // 队列空了，消费者等待
        }
        int value = queue.removeFirst();
        notifyAll(); // 唤醒可能等待的生产者
        return value;
    }
}

这里有个非常关键的细节：判断等待条件必须用while而不是if，因为线程被唤醒后，需要重新检查条件是否仍然满足。如果用了if，可能出现“虚假唤醒”导致队列溢出或空读。这是我最初踩过的一个坑，后来看Java并发编程的书才明白这是规范写法。

Lock + Condition

Java 5之后提供了显式锁Lock和Condition接口，功能比synchronized更丰富，可以实现多个等待队列，比如区分“生产者等待队列”和“消费者等待队列”，避免notifyAll把所有线程都唤醒，减少无谓的竞争。

BlockingQueue

实际业务开发中，直接手写wait/notify的场景已经很少，因为Java提供了BlockingQueue，比如ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue，内部已经封装好了线程安全的生产者消费者逻辑。你只需要往队列里put和take就行。

这引出了热词里面的“线程池的阻塞队列选择”——为什么线程池要配一个阻塞队列，因为任务的生产者（提交任务的主线程）和消费者（线程池的工作线程）天然就是生产者消费者模型，阻塞队列就是中间的缓冲和通信通道。

ThreadLocal

ThreadLocal是线程之间数据隔离的通信反面——它恰恰是“不通信”的手段。每个线程访问ThreadLocal变量时，都会复制一份独立的副本，互相之间不可见。在Web开发里，常用于保存用户登录信息或链路追踪ID，避免层层传递参数。

4.3 线程同步：互斥、死锁与线程安全

热词里出现了“线程互斥”和“线程死锁”。互斥是手段，死锁是互斥使用不当导致的灾难。

死锁发生的四个必要条件：

• 互斥条件：资源只能被一个线程独占
• 持有并等待：线程持有一个资源，同时等待另一个资源
• 不可剥夺：已持有的资源不能被其他线程强行抢走
• 循环等待：多个线程形成一个等待环路

排查死锁最直接的方式是，用jstack命令dump线程栈，可以看到类似“Found one Java-level deadlock”的输出，并指明哪些线程持有哪把锁、等待哪把锁。我在一个实际的订单系统中，遇到过两个线程分别持有A锁、B锁，又互相等对方的锁，最终导致接口全部卡死。解决方式是统一了锁的获取顺序，并且加上了超时获取锁的逻辑。

关于线程安全，一个基础结论是：

• 无状态对象永远是线程安全的
• 不可变对象是线程安全的（比如String、Long、Integer等包装类的大部分操作）
• 多个原子操作组合在一起，整体不一定是线程安全的

这也是为什么面试里总有人问“哪些Java类是线程安全的”的根本目的——不是要你背名单，而是考察你懂不懂“线程安全”的本质。

5. 线程池的正确打开方式：submit、execute与阻塞队列的选择

5.1 线程池为什么需要通信机制

线程池的本质，是复用线程、避免频繁创建销毁线程的开销。它由几个关键部分组成：核心线程数、最大线程数、阻塞队列、拒绝策略、线程工厂。

线程池的通信模型是这样的：提交任务的一方（主线程或其他线程）通过execute或submit把任务放进阻塞队列，线程池里的工作线程从队列里取任务执行。这个模型里，队列、线程的状态、任务的提交和获取，全都涉及并发访问，必须保证线程安全。所以线程池内部的所有关键数据结构几乎都做了同步处理。

5.2 submit和execute到底有什么区别

这是热词里被反复搜索的一个点，也是面试高频题。

java复制ExecutorService executor = Executors.newFixedThreadPool(4);

// execute：只能提交Runnable，没有返回值
executor.execute(() -> System.out.println("hello"));

// submit：可以提交Runnable或Callable，返回Future对象
Future<String> future = executor.submit(() -> "result");
String result = future.get();

三个核心区别：

1. 参数类型不同：execute只接受Runnable，submit可以接受Runnable和Callable。
2. 返回值不同：execute没有返回值，submit返回Future，可以通过Future获取任务执行结果或取消任务。
3. 异常处理不同：execute提交的任务如果抛出运行时异常，异常会直接传播到工作线程，可能导致线程终止；submit任务内部抛出的异常会被捕获并封装在Future里，只有调用future.get()时才会抛出ExecutionException。

这里有实际经验的细节：如果你需要拿到任务执行结果，或者需要抛出异常方便上层处理，优先用submit。如果只是发送一个fire-and-forget的任务，execute更轻量。

5.3 核心线程数、最大线程数、队列深度怎么配

热词里面出现了“java线程池的核心线程数工作原理”，这是必须讲透的。

核心线程数（corePoolSize）：线程池保持的常驻线程数量，即使这些线程闲着也不会销毁（除非设置了allowCoreThreadTimeOut）。
最大线程数（maximumPoolSize）：线程池允许创建的最大线程数量。
阻塞队列（workQueue）：存放等待执行的任务。

执行流程是：

1. 当提交任务时，如果当前线程数小于核心线程数，直接创建新线程执行任务
2. 如果当前线程数大于等于核心线程数，尝试把任务放入阻塞队列
3. 如果队列满了，且当前线程数小于最大线程数，创建新线程执行任务
4. 如果当前线程数已经等于最大线程数，执行拒绝策略

这就是“先核心、再排队、再扩容、最后拒绝”的顺序。很多人误解为“队列满了就立刻创建新线程”，这是不对的，实际是先排队，队列满了才扩容。

关于参数怎么配，没有银弹，只能按场景：

5.4 队列选有界还是无界，这是个安全选择题

无界队列（比如LinkedBlockingQueue不指定容量时）的优点是任务永远不会因为队列满而拒绝，比较适合突发流量，最大线程数参数形同虚设。但缺点非常致命：如果任务生产速度长期大于消费速度，队列会无限膨胀，最终导致内存溢出OOM。

有界队列（比如ArrayBlockingQueue指定容量）则强迫你在系统设计阶段就考虑清楚：队列满了怎么办？是丢弃任务、抛出异常、让提交线程自己执行，还是丢弃最旧的任务？这个选择对应四种拒绝策略：

• AbortPolicy：直接抛出RejectedExecutionException（默认策略）
• CallerRunsPolicy：提交任务的线程自己执行，不丢弃任务，适合不希望丢任务的场景
• DiscardPolicy：静默丢弃任务
• DiscardOldestPolicy：丢弃队列中最旧的任务，然后重新提交当前任务

我在实际项目里更推荐有界队列 + CallerRunsPolicy的组合，这样既能限制内存占用，又能在系统过载时通过“提交线程自己执行”来反向压力反馈，削峰填谷的效果很明显。

5.5 线程池的线程安全问题

线程池本身对外暴露的接口是线程安全的，但你提交的任务内部处理的数据是不是安全，完全由你自己负责。比如多个任务如果同时修改同一个ArrayList，就会产生并发问题。针对这种情况，要么用线程安全的集合（比如CopyOnWriteArrayList、ConcurrentHashMap），要么对共享资源加锁，要么把数据设计成不可变对象。

另外，热词里提到的“java+编写守护线程”和线程池也有关系：线程池内部的工作线程默认是非守护线程，所以即使主线程main执行完了，只要线程池没有调用shutdown，JVM就不会退出。如果你的主程序想退出却又一直被线程池挂着，记得主动调shutdown。

6. 实战问题排查：从进程与线程视角看疑难杂症

6.1 Java进程查不到、线程数异常怎么排查

热词里有“arthas启动无法获取jps进程”，这是一个实际运维中很常见的问题。jps是JDK自带的查看Java进程的工具，但如果当前用户和启动Java进程的用户不一致，jps默认是看不到对方进程的。或者，如果Java进程是以容器方式运行，而你在宿主机上执行jps，看到的也不是容器的Java进程。

用ps -ef | grep java却可以看到进程，是因为ps看到的是系统级的进程列表，而jps通过Java进程的临时文件来定位进程，权限和目录不一致会导致“看不到”。排查思路是切换到启动进程的同一用户再执行jps，或者直接用ps加jstack定位线程问题。

arthas本身是一个很强大的Java诊断工具，遇到“启动无法获取jps进程”时，我一般先确认当前用户，再确认Java进程是否存活，然后直接指定pid号来attach。

6.2 Windows任务管理器进程空白、无法结束线程

热词里有“任务管理器进程空白”和“windows杀死线程”。任务管理器打开后进程列表空白的原因比较多，常见的有：

• 当前账户权限不足，尝试用管理员身份打开任务管理器
• 系统资源不足，任务管理器本身卡死了
• 系统文件损坏，可以考虑重启资源管理器进程

至于“windows杀死线程”，严格来说Windows不像Linux那样可以单独对线程发信号，通常的做法是结束整个进程。如果你遇到某个进程僵死，可以用：

powershell复制# 查看监听端口和对应PID
netstat -ano | findstr :8080

# 结束进程
taskkill /F /PID 1234

如果taskkill提示权限不足，就用管理员权限的PowerShell再执行。

6.3 终端进程启动失败、winpty被移除的问题

热词里有一条很细节的问题：“终端进程启动失败: 启动期间发生本机异常(无法启动 conpty)。已移除 winpty”。这个问题经常出现在Windows上使用VSCode或Windows Terminal时，原因通常是系统更新后OpenSSH或ConPTY组件冲突，或者终端配置里显式引用了winpty路径，但系统上已经不存在这个程序。

解决办法通常是：

1. 检查终端设置里是否还配置了winpty相关路径，删除即可
2. 更新或修复Windows Terminal组件
3. 如果仍然不行，试试重启Windows Terminal进程或重启系统

这类问题和线程通信本身关系不大，但它属于“进程管理”范畴的常见故障，排查思路对做开发的人仍然有参考价值。

6.4 死锁、线程安全问题的标准排查流程

遇到线上接口卡死、CPU飙升、线程数异常增长这一类问题，我的排查步骤基本是固定的：

1. 先用top -Hp <pid>查看Java进程内哪个线程占CPU最高，记录线程ID
2. 用printf "%x\n" <线程ID>把十进制转十六进制
3. 用jstack <pid> | grep <十六进制线程ID>定位到对应线程的堆栈
4. 看一下线程状态，是RUNNABLE还是BLOCKED还是WAITING
5. 如果大量线程BLOCKED，用jstack或arthas的thread -b找出死锁，或者看它们都在竞争同一把锁
6. 结合代码，确认是数据库连接池满了、锁竞争激烈、还是线程池队列堆积

这套流程里jstack和arthas是核心工具。arthas比jstack更强大的一点是可以在线反编译、查看方法调用参数、甚至直接热更新代码，调试体验很好。但要注意，在线诊断工具在生产环境使用时要格外谨慎，尤其是热更新这类高危操作，非必要不要做。

6.5 线程池拒绝策略配置不合理导致的任务丢失

实际项目里经常遇到的一个问题是，线上突然出现“RejectedExecutionException”，排查后发现是有界队列太小、最大线程数太小，业务快速涌入时触发了拒绝策略。如果用的是默认的AbortPolicy，任务直接丢，而且会抛出异常。如果用的是DiscardPolicy，则异常都没有，任务直接悄悄消失，接入了监控平台都不一定发现。

所以我的建议是，任何时候都要给线程池配置一个兜底方案：

• 用CallerRunsPolicy保证任务不丢（但要注意调用方线程会被占用，可能引发链路阻塞）
• 或者自己实现RejectedExecutionHandler，把被拒绝的任务写入MQ或者日志文件，后续补偿处理

我在实践中更倾向于后者：拒绝时不抛异常，而是把任务序列化到磁盘或MQ，然后异步补偿执行。这样即使用户看到响应慢一点，也不会丢数据。

7. 语言与框架层面的通信封装：从C++到Java再到系统工程

热词里提到“c++进程和线程的通信方式”，这个话题值得单独说一说，因为C++的线程通信方式和Java有相似之处，但细节完全不同。

C++11标准库提供了std::thread、std::mutex、std::condition_variable、std::future、std::atomic等组件。C++的线程通信同样依赖共享内存加锁，但比Java更强调“零开销抽象”，所以你可能需要花更多精力管理内存生命周期。

比如C++里典型的生产者消费者模型，用的是mutex配合condition_variable，思路和Java的synchronized配合wait/notify是一样的：

cpp复制std::mutex mtx;
std::condition_variable cv;
std::queue<int> queue;

void produce(int v) {
    std::unique_lock<std::lock_guard<std::mutex>> lock(mtx);
    queue.push(v);
    cv.notify_one();
}

void consume() {
    std::unique_lock<std::mutex> lock(mtx);
    cv.wait(lock, [] { return !queue.empty(); }); // 防止虚假唤醒
    int v = queue.front();
    queue.pop();
}

注意C++的condition_variable::wait也要求传入一个谓词来防止虚假唤醒，这一点和Java的while循环本质相同。

在系统层面，像Nginx、Redis这样的高性能服务器，大量使用了“进程+线程混合模型”。Nginx的master进程负责管理worker进程，worker进程通过共享内存通信；Redis的CPU密集任务用单线程，但后台持久化又用了子进程。理解这些工程实践，会对“进程与线程通信”有更直观的认识。

8. 一些值得记住的实操心得

文章写到这里，主体内容已经覆盖了进程通信、线程通信、线程池、线程安全和故障排查。最后分享几个我自己在实际操作中沉淀下来的体会，谈不上全面，但都是踩过坑之后换来的经验。

第一，不要迷信“共享内存一定最快”。共享内存的传输效率确实高，但为了同步而引入的锁竞争，在高并发场景下可能吃掉你省下来的性能。在数据量中等、跨进程要求不高的场景下，反而更推荐Socket或消息队列，因为它们更容易做好流量控制和故障隔离。

第二，线程通信优先用成熟的并发容器，而不是自己手写锁。Java的ConcurrentHashMap、BlockingQueue、CopyOnWriteArrayList这些并发容器，经过了大规模线上验证，比大多数自研锁方案靠谱得多。如果你发现自己需要频繁手写复杂加锁逻辑，先回头看看是不是容器选错或者设计不够简化。

第三，排查线程问题，最先要看的不是代码，而是线程转储和监控数据。很多时候，CPU飙高、接口超时的问题，根本原因不在你眼下怀疑的这段代码里，而是在数据库连接、外部RPC、甚至GC线程上。数据先看懂，再动手改代码。

第四，线程池的配置永远不是一次性的。流量是变化的，系统的瓶颈也在变，所以线程池参数必须支持动态调整和监控。诸如setCorePoolSize这类方法的存在，就是提醒你不要把配置写死。线上跑一段时间后，结合QPS、TP99、队列积压量这些指标来调优，永远比迷信公式靠谱。

关于进程与线程通信方式，这次就梳理到这里。如果你正在做并发相关的开发或排查问题，希望这篇文章能帮上忙。