作者：Android面试官
进程间通信的经典实现
进程间通信（Inter-process communication，IPC）指运行在不同进程中的若干线程间的数据交换，可发生在一台机器上，也可通过网络跨机器实现。
共享内存、管道、UNIX Domain Socket 和 RPC 因高效稳定的优点几乎被应用在所有操作系统中。
共享内存
共享内存是一种常用的进程间通信机制，不同进程可以直接共享访问同一块内存区域，避免了数据拷贝，速度较快。实现步骤如下：
1. 创建内存共享区
Linux 通过 shmget 方法创建与特定 key 关联的共享内存块：
//返回共享内存块的唯一 Id 标识
int shmget(key_t key, size_t size, int shmflg);
2.映射内存共享区
Linux 通过 shmat 方法将某内存块与当前进程某内存地址映射：
//成功返回指向共享存储段的指针
void *shmat(int shm_id, const void *shm_addr, int shmflg);
3.访问内存共享区
其他进程要访问一个已存在的内存共享区的话，可以通过 key 调用 shmget 获取到共享内存块 Id，然后调用 shmat 方法映射。
4.进程间通信
当两个进程都实现对同一块内存共享区做映射后，就可以利用此内存共享区进行数据交换，但要自己实现同步机制。
5.撤销内存映射
进程间通信结束后，各个进程需要撤销之前的映射，Linux 可以调用 shmdt 方法撤销映射：
//成功则返回 0，否则出错
int shmdt(const void *shmaddr);
6.删除内存共享区
最后需要删除内存共享区，以便回收内存，Linux 可以调用 shctl 进行删除：
//成功则返回 0，否则出错，删除操作 cmd 需传 IPC_RMID
int shmctl(int shm_id, int cmd, struct shmid_ds *buf);
shmget 方法名言简意赅，share memory get ！其中 get 还有一层含义，为什么不叫 create 呢？之前如果创建过某一 key 的共享内存块，再次调用便直接返回该内存块，不会发生创建操作了。
管道
管道（Pipe）是操作系统中常见的一种进程间通信方式，一根管道有”读取”和”写入”两端，读、写操作和普通文件操作类似，并且是单向的。
管道有容量限制，当写满时，写操作会被阻塞；为空时读操作会被阻塞。
Linux 通过 pipe 方法打开一个管道：
//pipe_fd[0] 代表读端，pipe_fd[1] 代表写端，
int pipe(int pipe_fd[2], int flags);
以上方式只能用于父子进程，因为只有一个进程中定义的 pipe_fd 文件描述符只有通过 fork 方式才能传给另一个进程继承获取到，也正是因为这个限制，Named Pipe 得以发展，改变了前者匿名管道的方式，可以在没有任何关系的两个进程间使用。
UNIX Domain Socket
UNIX Domain Socket（UDS）是专门针对单机内的进程间通信，也称 IPC Socket，与 Network Socket 使用方法基本一致，但实现原理区别很大：
- Network Socket 基于 TCP/IP 协议，通过 IP 地址或端口号进行跨进程通信
- UDS 基于本机 socket 文件，不需要经过网络协议栈，不需要打包拆包、计算校验等
Android 中使用最多的 IPC 是 Binder，其次就是 UDS。
Remote Procedure Calls
RPC 即远程过程调用（Remote Procedure Call），RPC 是指计算机 A 上的进程，调用另外一台计算机 B 上的进程，其中 A 上的调用进程被挂起，而 B 上的被调用进程开始执行，当值返回给 A 时，A 进程继续执行。
调用方可以通过使用参数将信息传送给被调用方，而后通过传回的结果得到信息。
Java RMI 就是一种 RPC 框架，指的是远程方法调用 (Remote Method Invocation)，它能够让一个 Java 虚拟机上的对象调用另一个 Java 虚拟机中的对象的方法。
RPC 可以理解为一种编程模型，就像 IPC 一样，我们常说 Android AIDL 是一种 IPC 实现方式，也可以称为一种 RPC 方式。
同步机制的经典实现
信号量
信号量与 PV 原语操作是一种广泛使用的实现进程/线程互斥与同步的有效方法，Semaphore S 信号量用于指示共享资源的可用数量。
P 操作：
- S = S - 1
- 然后判断若 S 大于等于 0，代表共享资源允许访问，进程继续执行
- 若 S 小于 0，代表共享资源被占用，需等待别人主动释放资源，该进程阻塞放入等待该信号量的队列中，等待被唤醒
V 操作：
- S = S + 1
- 然后判断若 S 大于 0，代表没有正在等待访问该资源的进程，无需处理
- 若 S 小于等于 0，从该信号的等待队列中唤醒一个进程
Java 中的信号量的实现类为 Semaphore，P、V 操作分别对应 acquire、release 方法。
Mutex
Mutex 即互斥锁，可以和信号量对比来理解，信号量可以使资源同时被多个线程访问，而互斥锁同时只能被一个线程访问。也就是说，互斥锁相当于一个只允许取值 0 或 1 的信号量。
Java 中 ReentrantLock 就是互斥锁的一种实现。
管程
采用 Semaphore 机制的程序中 P、V 操作大量分散在程序中，代码易读性差，不易管理，容易发生死锁，所以引入了管程 Monitor。
管程把分散在各进程中的临界区集中起来进行管理，防止进程有意或无意的违法同步操作，便于用高级语言来书写程序，也便于程序正确性验证。
管程封装了同步操作，对进程隐蔽了同步细节，简化了同步功能的调用界面。用户编写并发程序如同编写顺序(串行)程序。
Java 中 synchronized 同步代码块就是 Monitor 的一种实现。
Linux Futex
Futex 全称 Fast Userspace muTexes，直译为快速用户空间互斥体，那他比普通的 Mutex 快在哪里呢？
Semaphore 等传统同步机制需要从用户态进入到内核态，通过一个提供了共享状态信息和原子操作的内核对象来完成同步。但大多数场景同步是无竞争的，不需要进入互斥区等待就可以直接获取到锁，但依然进行了内核态的切换操作，这造成了大量的性能开销。
Futex 通过 mmap 让进程间共享一段内存，当进程尝试进入互斥区或退出互斥区的时候，先查看共享内存中的 Futex 变量，如果没有竞争发生，则只修改 Futex 变量而不执行系统调用切换内核态。
Futex 的 Fast 就体现在对于大多数不存在竞争的情况，可以在用户态就完成锁的获取，而不需要进入内核态，从而提高了效率。
如果说 Semaphore 等传统同步机制是一种内核态同步机制，那 Futex 就是一种用户态和内核态混合的同步机制。
Futex 在 Android 中的一个重要应用场景是 ART 虚拟机，如果 Android 版本开启了 ART_USE_FUTEXES 宏，那 ART 虚拟机中的同步机制就会以 Futex 为基石来实现，关键代码如下：
// art/runtime/base/mutex.cc
void Mutex::ExclusiveLock(Thread* self){
#if ART_USE_FUTEXES
//若开启 Futex 宏就通过 Futex 实现互斥加锁
futex(...)
#else
//否则通过传统 pthread 实现
CHECK_MUTEX_CALL(pthread_mutex_lock,(&mutex_));
}
源码见 http://androidxref.com/7.0.0_r1/xref/art/runtime/base/mutex.cc
Android 中的进程间同步机制
了解了操作系统经典的同步机制后，再来看 Android 中是怎么实现的。
进程间同步 Mutex
Mutex 实现类源码很短，见 http://androidxref.com/7.0.0_r1/xref/system/core/include/utils/Mutex.h
注意这里说的 Mutex 和上面的 mutex.cc 是两个东西，mutex.cc 是 ART 中的实现类，支持 Futex 方式；而 Mutex.h 只是对 pthread 的 API 进行了简单封装，函数声明和实现都在 Mutex.h 一个文件中。
源码中可以看到一个枚举类型定义：
class Mutex {
public:
enum {
PRIVATE = 0,
SHARED = 1
};
其中 PRIVATE 代表进程内同步，SHARED 代表进程间同步。Mutex 相比 Semaphore 较简单，只有 0 和 1 两种状态，关键方法为：
inline status_t Mutex::lock() {//获取资源锁，可能阻塞等待
return -pthread_mutex_lock(&mMutex);
}
inline void Mutex::unlock() {//释放资源锁
pthread_mutex_unlock(&mMutex);
}
inline status_t Mutex::tryLock() {//获取资源锁，不论成功与否都立即返回
return -pthread_mutex_trylock(&mMutex);
}
当要访问临界资源时，需先通过 lock() 获得资源锁，如果资源可用会此函数会立即返回，否则阻塞等待，直到其他进程(线程)调用 unlock() 释放了资源锁从而被唤醒。
tryLock() 函数存在有什么意义呢？它在资源被占用的情况下，不会像 lock() 一样进入等待，而是立即返回，所以可以用来试探性查询资源锁是否被占用。
加解锁的自动化操作 Autolock
Autolock 为 Mutex.h 中的一个嵌套类，实现如下：
// Manages the mutex automatically. It'll be locked when Autolock is
// constructed and released when Autolock goes out of scope.
class Autolock {
public:
inline Autolock(Mutex& mutex) : mLock(mutex) { mLock.lock(); }
inline Autolock(Mutex* mutex) : mLock(*mutex) { mLock.lock(); }
inline ~Autolock() { mLock.unlock(); }
private:
Mutex& mLock;
};
如注释所示，Autolock 会在构造时主动去获取锁，在析构时会自动释放掉锁，也就是说，在生命周期结束时会自动把资源锁释放掉。
这就可以在一个方法开始时为某 Mutex 构造一个 Autolock，当方法执行完后此锁会自动释放，无需再主动调用 unlock，这让 lock/unlock 的配套使用更加简便，不易出错，
条件判断 Condition
条件判断的核心思想是判断某 “条件” 是否满足，满足的话马上返回，否则阻塞等待，直到条件满足时被唤醒。
你可能会疑问，Mutex 不就可以实现吗，干嘛又来一个 Condition，它有什么特别之处？
Mutex 确实可以实现基于条件判断的同步，假如条件是 a 为 0，实现代码会是这样：
while(1){
acquire_mutex_lock(a); //获取 a 的互斥锁
if(a==0){
release_mutex_lock(a); //释放锁
break; //条件满足，退出死循环
}else{
release_mutex_lock(a); //释放锁
sleep()；//休眠一段时间后继续循环
}
}
什么时候满足 a==0 是未知的，可能是很久之后，但上面方式无限循环去判断条件，极大浪费 CPU。
而条件判断不需要死循环，可以在满足条件时才去通知唤醒等待者。
Condition 源码见 http://androidxref.com/7.0.0_r1/xref/system/core/include/utils/Condition.h ，它和 Mutex 一样也有 PRIVATE、SHARED 类型，PRIVATE 代表进程内同步，SHARED 为进程间同步。关键方法为：
//在某个条件上等待
status_t wait(Mutex& mutex)
//在某个条件上等待，增加超时机制
status_t waitRelative(Mutex& mutex, nsecs_t reltime)
//条件满足时通知相应等待者
void signal()
//条件满足时通知所有等待者
void broadcast()
Mutex+Autolock+Condition 示例
我们熟知的 LinkedBlockingQueue，源码见 http://androidxref.com/7.0.0_r1/xref/frameworks/av/media/libstagefright/webm/LinkedBlockingQueue.h
class LinkedBlockingQueue {
List<T> mList;
Mutex mLock;
Condition mContentAvailableCondition;
T front(bool remove) {
Mutex::Autolock autolock(mLock);
while (mList.empty()) {
mContentAvailableCondition.wait(mLock);
}
T e = *(mList.begin());
if (remove) {
mList.erase(mList.begin());
}
return e;
}
//省略...
void push(T e) {
Mutex::Autolock autolock(mLock);
mList.push_back(e);
mContentAvailableCondition.signal();
}
}
调用 front 方法出队元素时，首先获取 mLock 锁，然后判断若列表为空就调用 wait 方法进入等待状态，待 push 方法入队元素后通过 signal 方法唤醒。
front 方法占有了 mLock 锁，push 方法不应该阻塞在第一行代码无法往下执行吗？
很简单，wait 方法中释放了 mLock 锁，见 pthread_cond.cpp：http://androidxref.com/7.0.0_r1/xref/bionic/libc/bionic/pthread_cond.cpp#173
可以不依赖 Mutex 仅通过 Condition 的 wait/signal 实现吗？
不行，对 mList 的访问需要加互斥锁，否则可能出现 signal 无效的情况。比如 A 进程调用 front ，判断 mList 为空，即将执行 wait 方法时，B 进程调用 push 方法并执行完，那么 A 进程将得不到唤醒，尽管此队列中有元素。
最后
不论什么样的操作系统，其技术本质都类似，而更多的是把这些核心的理论应用到符合自己需求的场景中。
我这里有一份Android行业的大牛自己收录整理的 Android学习PDF+架构视频+源码笔记 ，还有高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。
如果你需要，可以 点击获取。
不要满足于自己的既有知识，离开舒适圈，学无止境，祝你成功。