开篇做Android系统开发这些年最吃亏的往往是那些被文档一笔带过的底层原语——socketpair算一个典型。最近排查一个native服务的事件唤醒问题最终定位到一对socketpair的阻塞读上顺手把AOSP相关代码完整啃了一遍才发现这东西在系统源码里出现的频率远高于普通业务开发者的认知。这篇文章不是API文档翻译而是按照我读完源码之后的理解把socketpair从内核到Android框架、再到实际落地的完整链路重新捋一遍。适合两类人看一类是准备深挖Android Framework、经常在AOSP代码里和原生Socket打交道的系统开发另一类是在自己的App里想通过ParcelFileDescriptor实现跨进程实时通信、但总觉得文档不够解渴的应用开发。如果你只是想知道怎么在一个Activity里用socketpair唤醒线程这里也有可以直接抄的代码。1. socketpair到底解决了什么问题先建立直观认识1.1 一次调用返回两个互相牵着的fdsocketpair的函数签名在Linux上很固定#include sys/socket.h int socketpair(int domain, int type, int protocol, int sv[2]);调用一次返回两个文件描述符sv[0]和sv[1]。这两个fd天生就是连接好的从sv[0]写入的数据对端sv[1]可以直接读出来反过来从sv[1]写的数据sv[0]也能读到。而且它是全双工两个方向互不干扰不需要bind、listen、accept这些动作省去了一整套socket服务端生命周期。这里有个容易产生的错觉以为sv[0]是客户端、sv[1]是服务端。实际上两个fd的地位完全对等没有主从关系。你往任意一端写另一端就能读哪一端留在本进程哪一端传给别的进程完全由你决定。在生产环境里最常见的domain是AF_UNIX也就是Unix域套接字。type则根据需求选SOCK_STREAM字节流有序可靠或SOCK_DGRAM数据报保留消息边界。protocol几乎总是传0让内核根据domain和type自动选择。1.2 socketpair、pipe、eventfd三者怎么选Android系统源码里用于线程唤醒和进程通信的原语有好几个我习惯先把它们放在一张表里对比再决定用哪个维度socketpairpipeeventfd通信方向全双工一条连接双向传输半双工一个方向一条管道本质是计数器通常单向唤醒是否支持跨进程支持支持支持但很少这么用消息边界SOCK_DGRAM / SOCK_SEQPACKET 支持无边界计数无边界概念能否附带传递fd支持SCM_RIGHTS支持SCM_RIGHTS不支持接入epoll/Looper支持支持支持性能更好典型使用场景双向通信、事件数据一起传单向日志流、输入输出重定向纯事件通知、Java/Java线程唤醒我个人的选择习惯如果只是线程间通知有活干了eventfd最轻量这也是Android Java层MessageQueue底层选择eventfd而不是管道的原因如果是日志、字节流这种单方向传递pipe足够如果两边要互相发命令、回结果、或者还要传文件描述符那socketpair是最顺手的选择。不少人在看AOSP代码时看到socketpair调用会下意识当成普通socket处理然后开始找bind/connect的代码结果怎么都找不到。这就是没理解它的定位它不是用来建立一个客户端-服务端连接而是直接预连好的一条双向通道。2. 从系统调用到内核socketpair的源码实现路径2.1 Bionic层如何把Java层调用送进内核Android上的C库是Bionic所有系统调用最终都要经过它。Bionic里socketpair的实现路径非常薄基本就是一次系统调用封装bionic/libc/bionic/socketpair.cpp里的socketpair函数本质上是__socketpair这个带前缀的内核wrapper负责把参数从用户态寄存器传递到内核态并处理返回值和errno。Java层也有对应的入口比如android.system.Os.socketpair()。它最终通过JNI走到libcore的native层再调用Bionic的socketpair。所以不论你从C代码调用还是从Java调用最终落点都是同一个系统调用。了解这条链路对排查问题很有帮助。如果某个socketpair调用失败了你需要先确认errno是什么EMFILE是fd数达到上限ENFILE是系统文件表满EAFNOSUPPORT是domain不支持。而Android上最常见的是第一个因为应用或者系统服务的fd数被rlimit限制住了。2.2 内核里两个socket是怎么配对成功的真正精彩的部分在Linux内核。以AF_UNIX为例整个流程大概是这样以Linux 5.x/6.x内核和Android同源逻辑为参考socketpair系统调用进入内核的net/socket.c对应的处理函数是__sys_socketpair。内核根据domain、type、protocol创建两个独立的struct socket对象每个socket都会走对应protocol family的create回调。AF_UNIX会走到unix_create。对于普通socket服务端unix_create之后只是创建了一个未连接的socket还要靠bind/listen/accept一步步建立连接。但socketpair不一样内核直接调用unix_socketpair把两个新创建的sock对象互相指为peer并设置状态为TCP_ESTABLISHED表示连接已经建立。最后内核把这两个socket对应的文件描述符分别填入用户传入的sv[0]和sv[1]返回到用户态。关键点是互相指为peer。两个socket对象各自独立底层有自己独立的发送队列和接收队列但它们的对端就是对方。于是写入A的发送队列B从接收队列里就能读到反过来同理。因为双方的连接状态在创建时就已经是established后续的read/write不需要任何握手这就是它比本地socket服务端连接快一大截的原因。值得注意的一个细节这两个fd在进程里表现为两个不同整数的fd但它们并不是同一个struct file的引用。虽然socketpair只被调用了一次返回的两个fd各自对应不同的file结构只是底层socket对象互相对接。别把这当成同一个对象来管理否则后面做fd生命周期管理时会踩坑。2.3 字节流还是数据报SOCK_STREAM与SOCK_DGRAM的底层差异选择type时很多人随手写SOCK_STREAM但没意识到这会带来什么语义差异。SOCK_STREAM是字节流模式和TCP类似对端一次write写入的数据本端可以分多次read读出来反过来多次write的数据也可能在一次read中被全部读走。也就是说没有消息边界需要应用层自己定协议——比如固定长度头部加数据体长度字段指明后面有多少字节。不少人在初次使用socketpair进行消息通信时发现收到的是半截消息其实就是这个原因。SOCK_DGRAM是数据报模式一次send对应对端一次recv接收消息边界天然保留。但因为报文有长度上限而且在缓冲区满时无法再塞入新报文收到EAGAIN或者ENOBUFS都需要处理。SOCK_SEQPACKET则介于两者之间保留边界、保证顺序和可靠传输不过支持它的平台和上层封装不如前两者普遍。Android框架层对外暴露的ParcelFileDescriptor.createSocketPair()默认使用的是SOCK_STREAM所以你在Java层拿到这对PFD时粘包问题从一开始就需要面对。后面我会给出具体的协议设计思路。3. Android框架层的两个入口为什么都值得掌握3.1 ParcelFileDescriptor.createSocketPair()的JNI实现在Java层用socketpair绕不开的一个API是ParcelFileDescriptor.createSocketPair()。它的实现不在Java层而是在JNI层源码位置在frameworks/base/core/jni/android_os_ParcelFileDescriptor.cpp。JNI实现做的事情很直接调用C库的socketpair(AF_UNIX, SOCK_STREAM, 0, fds)。如果失败抛出IOException并携带errno信息。成功时把fds[0]和fds[1]两个裸fd分别包装成ParcelFileDescriptor对象。返回ParcelFileDescriptor[2]数组给Java层。这个API最棒的特性是ParcelFileDescriptor实现了Parcelable可以直接放进Bundle或者作为AIDL方法参数传输。Binder驱动在跨进程传输Parcel时会自动把fd复制给对端进程。所以你可以在进程A创建一对socketpair把其中一端传给进程B自己保留另一端然后这对fd就成了A和B之间的全双工通道。这个方法默认创建的是SOCK_STREAM不适合传长度不固定的二进制块时不做协议解析。另一个缺点是JNI层没有暴露type参数你没法通过这个API直接拿到SOCK_DGRAM或SOCK_SEQPACKET。3.2 android.system.Os.socketpair()不带包装的原生入口如果需要完全控制domain和typeAndroid在android.system包里提供了一个更接近系统调用的入口Os.socketpair(int domain, int type, int protocol, int[] fds)。注意它返回voidfd是写到调用者传入的int[2]数组里。用法示例int[] fds new int[2]; Os.socketpair(OsConstants.AF_UNIX, OsConstants.SOCK_DGRAM, 0, fds);走这个入口你能拿到裸fd但要想在Java层优雅使用还得自己想办法把它包装成FileDescriptor或者ParcelFileDescriptor。在较新的API上可以用ParcelFileDescriptor.fromFd(fd)如果不想依赖新API建议优先使用ParcelFileDescriptor.createSocketPair()因为它已经帮你把包装做完了。我比较推荐的做法是自定义消息格式的场景用Os.socketpair自己管理type只做流式数据传递的场景直接用ParcelFileDescriptor.createSocketPair()。这样代码里不会出现一堆hide API的依赖。3.3 在Looper/事件循环里用socketpairnative层的注册与唤醒Android系统服务里大量使用ALooper来监听fd事件socketpair在这里的价值很大。它的套路是创建一对socketpair。把读端fd通过ALooper_addFd注册到目标Looper上。事件产生线程往写端写一个字节。Looper所在的线程被唤醒通过回调处理事件。代码骨架如下int fds[2]; int rc socketpair(AF_UNIX, SOCK_STREAM, 0, fds); if (rc ! 0) return; // 把读端注册到 Looper ALooper_addFd(looper, fds[0], ALOOPER_POLL_CALLBACK, ALOOPER_EVENT_INPUT, onSocketEvent, this); // 在事件产生线程里 write(fds[1], x, 1);这里有个必须处理的细节socketpair返回的fd默认是阻塞的。如果注册到ALooper_addFd之后没有把读端设为非阻塞一旦回调还没能把数据读走后续事件到来时可能阻塞在read上直接把整个Looper卡死。所以我通常创建完fd立刻设置O_NONBLOCKint flags fcntl(fds[0], F_GETFL, 0); fcntl(fds[0], F_SETFL, flags | O_NONBLOCK);另外要记住ALooper触发ALOOPER_EVENT_INPUT之后默认是水平触发只要可读数据还在就会持续回调。所以回调里必须把socket里的数据读干净否则会出现忙循环。对于socketpair写入端只写一个唤醒字节读端一次性把它读走即可。4. 四个能直接落地的使用场景从最简单的线程唤醒到跨进程双向通信4.1 进程内线程间事件通知一个可复用的SocketWakeup实现很多业务场景需要一个线程阻塞等待另一个线程按需唤醒它。用ConditionVariable加标志位可以做但状态一多就很容易漏唤醒或者错过唤醒。socketpair的天然阻塞/非阻塞模型反而更直白。Java层一个最小化实现ParcelFileDescriptor[] pair ParcelFileDescriptor.createSocketPair(); // 工作线程 new Thread(() - { byte[] buf new byte[1]; while (true) { int n Os.read(pair[0].getFileDescriptor(), buf, 0, 1); if (n 0) { handleEvent(); } } }).start(); // 触发线程 Os.write(pair[1].getFileDescriptor(), new byte[]{1}, 0, 1);注意这里的handleEvent()执行完下一次循环会继续阻塞在Os.read上。这个模型好处是唤醒事件不会丢失因为写端写入的字节会一直待在接收缓冲区里直到读端把它读走。如果你在业务状态里已经确认这个事件不需要处理了那也得先把字节读走否则下次还会触发。如果你希望一个线程同时等socketpair事件和业务锁可以把读端fd挂到Selector或者native的Looper上不要让线程简单阻塞在read。4.2 通过Binder把另一端抛给另一个进程socketpair最大的价值还是跨进程。跨进程实时通信很多人第一反应是用Binder回调、ContentProvider或者LocalSocket。但在两个进程之间建立一条会话式双向通道时socketpair往往更干净。进程A创建socketpairParcelFileDescriptor[] pair ParcelFileDescriptor.createSocketPair();保留pair[0]把pair[1]作为AIDL方法参数传给进程Binterface IWorker { void setupChannel(in ParcelFileDescriptor channel); }进程B收到PFD之后直接就可以用同一个fd读写。两边不需要自己再实现listen/accept逻辑也不用处理连接建立的状态机。Binder驱动在传输过程中已经帮我们把fd复制到了对端对端拿到的是有效可用的fd。这种模式特别适合一个进程负责分发任务、另一个进程负责执行的架构。任务请求用Socketpair的流发送结果也用同一条流返回不比用Binder反复跨进程调用慢而且不会受Binder事务缓冲区大小限制。Binder传输大文件时单次事务有1MB上限限制但socketpair本质是内核socket你完全可以按块读写避开这个限制。4.3 用SCM_RIGHTS通过socketpair传递文件描述符Linux上Unix域socket有一项非常强大的能力可以通过sendmsg配合SCM_RIGHTS控制消息把一个进程的文件描述符发送给另一个进程对端recvmsg时能把fd完整地接收下来。socketpair的两个fd天然支持这个能力。这个场景在Android上大多数时候被Binder的fd传递替代了因为在Binder接口里直接传ParcelFileDescriptor就可以了。但当你处在没有Binder可用的native模块里或者不想引入Binder依赖时sendmsgSCM_RIGHTS是一个轻量级方案。使用要点需要引入sys/socket.h、sys/un.h等头文件。构造struct msghdr和一个struct cmsghdr把要传递的fd作为辅助数据填充进去。sendmsg之前确认对端已经准备好接收否则消息发出去没人读fd会在对端缓冲区滞留。每个SCM_RIGHTS消息能携带的fd数量有限内核不同版本的上限不同现实中一次传个十几个足够不要设计成一次传几百个fd。这里有我踩过的坑传递fd时发送端一旦发送成功这个fd在发送进程中依然存在需要主动close否则会泄漏。对端recvmsg收到的fd是一个新的文件描述符和发送端的fd编号没有任何关系。4.4 把Binder回调调度到自己的业务线程系统服务经常遇到一类问题Binder回调是跑在Binder线程池的随机线程上的如果这个回调要更新UI或者操作某个单线程Looper维护的对象直接执行会有线程安全问题。一种常见解法是用socketpair做线程切换在业务线程启动时创建socketpair把读端挂到业务线程的Looper上。注册一个收到事件就执行待处理任务的回调。Binder回调线程不直接操作业务对象而是往socketpair写端写入一个字节并通知业务线程去执行真正需要做的事。这样Binder回调只负责投递消息业务操作永远在固定线程执行。比起用Handler.post这种方式不依赖Handler线程也不受Handler消息队列中的延迟影响在native服务里尤其常见。AOSP里能看到这种模式的变体有模块用管道有模块用eventfd也有模块直接使用socketpair。选socketpair的好处是顺带能把业务数据和唤醒信号放在同一条通道里减少一次锁竞争。5. 常见坑和优化建议实践经验总结5.1 关闭语义与fd泄漏socketpair的使用者经常在fd生命周期上翻车。这里有几个非常实际的问题如果进程fork了子进程子进程会继承两个fd。父子进程如果不各自close不用的那一端对端就永远感知不到EOF因为fd的引用计数不为零。正确做法是父子进程各保留自己的一端立即关闭另一端。Java层用ParcelFileDescriptor.AutoCloseInputStream和AutoCloseOutputStream时有一个隐藏陷阱它们都持有一个对底层fd的引用任何一个流被close最终都会把整个ParcelFileDescriptor的fd关掉。如果你同时开了一个输入流和一个输出流希望一个负责读、一个负责写一旦其中一个被关闭另一个也就废了。解决思路有两个如果只是单向通信直接用一个PFD输入流处理读、另一个PFD输出流处理写。但这意味着要创建两对socketpair各管一个方向。如果需要双向通信且不想被流关闭逻辑纠缠建议直接用Os.read和Os.write操作同一个fd自己管理fd的生命周期不要用包装好的Input/OutputStream。动态创建的socketpair用完后必须close两端。系统服务里如果把fd注册到了ALooper_addFd先移除监听再close否则可能发生回调时fd已经关闭的竞态。5.2 粘包、背压与缓冲区默认的SOCK_STREAM字节流没有消息边界跨进程传输数据时光靠write一段数据就以为对方read到同样一段数据是不够的。设计协议时我会在每条消息前面加一个固定长度的头部头部里写明消息长度[4字节消息长度][消息体...]这样对端先读固定4字节解出消息长度再读指定长度的消息体循环处理。注意读满4字节和读满消息体不一定一次read就完成需要循环读取直到读满利用read返回0表示对端关闭来退出。背压问题同样容易被忽略。如果发送端写得太快对端读得太慢socket的发送缓冲区会逐渐填满。阻塞模式下write会卡住发送端非阻塞模式下会返回EAGAIN需要让发送线程等待可写事件。这正是socketpair比简单内存队列更真实的地方——它会直接反馈消费速度让生产者和消费者的速度被迫对齐。调整缓冲区大小时不要盲目把SO_SNDBUF和SO_RCVBUF设得很大。内核可能会把用户设置的数值按倍数扩展内存占用不小。先按默认值跑出现背压再按业务数据量调整通常4KB到256KB已经覆盖大部分场景。5.3 非阻塞模式下EPIPE与EAGAIN的处理对端关闭连接后本端继续写入会触发SIGPIPE信号默认行为是直接终止进程。这在服务型进程里尤其危险因为一个无效写入可能把整个进程带走。处理方式有两类在native代码里对socketpair的fd使用send(fd, buf, len, MSG_NOSIGNAL)发送数据而不是write。MSG_NOSIGNAL可以避免内核发送SIGPIPE信号让错误通过返回值暴露出来方便你判断对端是否已经关闭。如果用的是write要么在进程里忽略SIGPIPE信号要么确保代码逻辑永远不会对已关闭端写入。后者很难保证所以建议首选MSG_NOSIGNAL。非阻塞模式下写入时缓冲区满返回EAGAIN这不代表出错而是代表当前无法立即写入。需要把fd注册到事件循环中监听可写事件等ALOOPER_EVENT_OUTPUT或poll的可写通知到来后再继续写。有些新人看到EAGAIN就当失败处理直接丢数据这是最常见的坑。另外Java层做非阻塞read时Os.read对非阻塞fd没有数据时会抛出ErrnoExceptionerrno是EAGAIN。捕获这个异常时需要区分没有数据和对端关闭两种情形read返回-1且errno为EAGAIN才表示暂时没数据返回0才表示对端关闭。5.4 几个实用的调试手段排查电socketpair问题时我经常用这几招ls -l /proc/pid/fd查看进程的fd列表以socket:[inode编号]出现的就是socketpair一端。cat /proc/net/unix查看所有Unix域socketsocketpair创建的socket没有路径Type列会显示STREAM或DGRAM通过Inode和fd列表对应起来。如果怀疑卡在阻塞读写上用strace -p pid -e traceread,write,recvmsg,sendmsg,epoll_wait看现场比对发送端和接收端的调用栈。业务侧觉得数据没到先确认写端有没有触发EPIPE再读端有没有把数据从缓冲区读走。很多时候不是socketpair的问题而是数据一直躺在接收缓冲区里没人读。最后再说一点个人体会我在模块里真正落地socketpair之后最大的收益是把唤醒和业务数据统一到了同一条通道上。原来需要“一个锁保护状态 一个条件变量唤醒 一个队列搬运数据”的事现在直接变成socketpair两端互相收发状态少了、锁竞争也少了。最让我意外的是这种底层原语在Android系统各组件里出现频率极高读源码时如果你能一眼认出它很多看似复杂的线程调度逻辑都能瞬间拆解成一人听话、一人喊这么简单。如果后续要继续深挖建议沿着这条线再去看看Android里LocalSocket和ParcelFileDescriptor在nativeloader、statsd等模块中的组合玩法那又是一堆可以写几千字的素材。
