1. IPC基础概念：什么是IPC、进程间通信的必要性、常见的IPC方式
各位同学，咱们今天聊聊IPC。嗯，IPC这三个字母，全称是Inter-Process Communication，翻译过来就是「进程间通信」。说白了，就是让两个或多个进程之间能互相传话、递数据。
你可能会问：「进程之间为什么要通信？各干各的不行吗？」
我刚开始做嵌入式开发时也这么想。直到有一次，我负责一个数据采集系统——一个进程负责从传感器读数据，另一个进程负责把数据存到数据库，还有一个进程负责在界面上显示波形。这三个进程各干各的，数据怎么传？总不能靠人眼看了再手动输入吧？
所以，IPC的必要性就在这里：进程之间需要协作，协作就需要通信。
1.1 什么是IPC
IPC，就是操作系统提供给不同进程之间交换数据或同步行为的一套机制。你可以把它想象成「进程之间的电话线」。
每个进程都有自己的独立地址空间，一个进程不能直接访问另一个进程的内存。这就好比两个人各住一间房，房门紧锁。你想给对方递张纸条，总不能把墙砸了吧？IPC就是那个「门缝」——让数据能安全地传递过去。
核心要点：IPC解决了三个问题——数据传输、共享数据、进程同步。
1.2 为什么需要进程间通信
我总结了一下，实际项目中需要IPC的场景，无非这么几种：
- 数据共享：一个进程采集数据，另一个进程处理数据。比如摄像头采集进程把图像传给AI识别进程。
- 任务分工：大系统拆成多个小进程，各管一摊。比如上位机里，UI进程只管界面，后台进程只管逻辑。
- 资源隔离：有些模块容易崩溃，比如第三方库。把它单独放一个进程里，崩了也不影响主程序。我见过太多因为一个插件崩溃导致整个上位机挂掉的案例了。
- 权限分离：有些操作需要高权限，比如写硬件寄存器。把高权限操作封装成一个独立进程，其他进程通过IPC请求它干活。
你想想看，如果没有IPC，这些场景怎么实现？要么把所有代码塞进一个进程，要么用文件传数据——前者容易崩，后者太慢。所以IPC是绕不开的。
1.3 常见的IPC方式
IPC的方式有很多种，我挑最常用的五种来讲。每种都有它的脾气，选对了事半功倍，选错了……嗯，我踩过不少坑。
1.3.1 管道（Pipe）
管道是最古老的IPC方式之一。它就像一根水管，一头进水，一头出水。数据从一端写入，从另一端读出。
管道分两种：
- 匿名管道：只能用于父子进程或兄弟进程之间。我早期做Linux下的小工具时经常用，简单粗暴。
- 命名管道（FIFO）：不要求进程有亲缘关系，任意两个进程都能用。Windows和Linux都支持。
我的经验：管道适合小数据量的简单通信。如果你要传几百兆的视频流，别用管道——它本质上是字节流，没有消息边界，而且效率不高。
1.3.2 消息队列（Message Queue）
消息队列比管道高级一点。它把数据封装成「消息」，每条消息有自己的类型和长度。进程可以按类型接收消息，不用一股脑全收。
我记得有一次做工业控制的上位机，需要把报警信息、状态数据、控制指令分开处理。用消息队列就特别合适——报警消息设成类型1，状态数据设成类型2，控制指令设成类型3。接收方只收自己关心的类型，清爽得很。
优点：消息有边界，不会粘包；支持优先级；异步通信。
缺点：消息大小有限制；系统开销比共享内存大。
1.3.3 共享内存（Shared Memory）
共享内存，说白了就是让两个进程「共用一块内存」。这是效率最高的IPC方式——数据不用复制来复制去，直接读写同一块内存就行。
但这里有个大坑：同步问题。两个进程同时写同一块内存，数据就乱了。所以共享内存通常要配合信号量或互斥锁一起用。
我曾经在一个高速数据采集项目里用过共享内存。采集进程每秒产生10万条数据，显示进程要实时刷新波形。用管道？太慢。用消息队列？消息太多会溢出。最后选了共享内存+信号量，性能直接拉满。
注意：共享内存虽然快，但编程复杂度高。你得自己处理锁、竞争条件、死锁等问题。新手慎用。
1.3.4 信号量（Semaphore）
信号量不是用来传数据的，它是用来「同步」的。你可以把它想象成一个计数器，用来控制多个进程对共享资源的访问。
举个例子：打印机只有一个，三个进程都想打印。信号量初始值为1，谁拿到信号量谁就能打印，打印完释放信号量。这样就不会出现打印内容混在一起的情况。
我习惯把信号量分成两种：
- 二值信号量：只有0和1，相当于互斥锁。
- 计数信号量：可以大于1，控制多个资源的访问。
嗯，这里要注意：信号量操作是原子性的，不会被中断。这是操作系统保证的。
1.3.5 Socket
Socket是IPC里最「万能」的一种。它不仅能用于同一台机器上的进程通信，还能用于不同机器之间的通信——网络通信就是靠Socket实现的。
Socket分很多种：
| 类型 | 说明 | 典型场景 |
|---|---|---|
| Unix Domain Socket | 同一台机器上，效率高 | 本地进程间通信 |
| TCP Socket | 面向连接，可靠 | 远程控制、文件传输 |
| UDP Socket | 无连接，速度快 | 实时数据流、视频传输 |
我做上位机开发时，最常用的是TCP Socket。因为上位机通常要跟下位机（比如PLC、单片机）通信，下位机一般通过以太网把数据发上来。这时候用Socket最自然。
避坑指南：我曾经在Windows上用Socket做本地IPC，结果发现性能不如命名管道。后来查资料才知道，Windows的本地Socket实现有额外开销。所以，同一台机器上优先用命名管道或共享内存，跨机器才用Socket。
1.4 如何选择IPC方式
说了这么多，你可能会问：「那我到底该用哪种？」
我个人的选择逻辑是这样的：
- 数据量小、简单通信 → 管道或消息队列
- 数据量大、追求性能 → 共享内存 + 信号量
- 需要同步控制 → 信号量
- 跨机器通信 → Socket（TCP或UDP）
- 同一台机器、跨语言 → Socket或命名管道
当然，实际项目中往往不是只用一种。比如我做过的一个视觉检测系统：采集进程和算法进程之间用共享内存传图像数据，算法进程和UI进程之间用消息队列传检测结果，UI进程和远程服务器之间用Socket传日志。各取所长，才是正道。
总结一句话：IPC没有银弹，理解每种方式的优缺点，根据场景选型，才是工程师该做的事。
好了，这一章就到这里。下一章咱们深入讲讲管道和消息队列的具体实现，我会带上代码示例，手把手教你写。到时候见。