在多线程应用程序中创建套接字文件描述符（sock fd）答案

【问题标题】：Creating socket file descriptors(sock fd) in a multi-threaded application在多线程应用程序中创建套接字文件描述符（sock fd）
【发布时间】：2017-03-31 00:53:24
【问题描述】：

我有一个具有 2 个线程的多线程应用程序。每个线程服务一个不同的接口。每当需要通过接口发出消息时，相应的线程就会打开一个套接字（获取一个fd）并发送消息并关闭fd。问题是，当我让两个线程都运行时，套接字没有被重用，我看到 /proc//fd 中的 fd 编号增加了。我也可以从日志中验证这一点。

相信问题在于该线程甚至在另一个线程关闭它之前就请求了一个 fd。所以操作系统返回下一个可用的 fd 编号，这将继续进行。

线程1打开一个tcp socket，线程2打开一个can(controller area network) socket

time    thread1      thread2
 0       req fd       idle
 1       fd 1         req fd
 2       close fd1    fd 2
 3       req fd       close fd 2
 4       fd 3         req fd
 5       close fd 3   fd 4

如果我把它写下来，我相信这就是它的样子。我怎样才能确保 fd 号码不会继续增长？我在 ARM 处理器上运行 32 位 linux。

【问题讨论】：

什么样的套接字？
线程1打开一个tcp套接字，线程2打开一个can（控制器局域网）套接字
我假设的 Posix 套接字？
如果最大文件描述符值为 127，我猜您正在使用某种在 8 位微控制器上运行的嵌入式操作系统。不要关闭套接字。应该没有必要。
@DavidCullen，我在 ARM 处理器上运行 32 位 Linux。我将 sockfd 作为 int8_t 返回，这解释了 127 的限制。但我仍然想知道如何确保 fd 号码不会增长。软件架构使得每条消息都作为新连接发送，因此我无法更改。

标签： c multithreading sockets

【解决方案1】：

事实证明，在一种情况下，在 can 代码中我没有关闭 fd！

【讨论】：

【解决方案2】：

套接字描述符值中的间隙不是资源泄漏的证据。分配文件描述符是线程安全的操作（可能所有系统调用也是如此）。如果正确关闭每个套接字，就不会出现泄漏。

您可以使用以下命令监控打开文件描述符的数量如何变化：

watch --interval=0.5 "sh -c 'lsof -p YOUR_PROGRAM_PID_HERE | wc -l'"

如果数量增加，那么可能有一些套接字（或其他 FD）没有关闭。

如果您仍然不确定是否存在描述符泄漏，您可以尝试在程序退出时以编程方式计算打开文件描述符的数量，方法是检查 /proc/self/fd 目录中的条目数，或者通过反复尝试关闭所有描述符并计算有多少调用没有返回EBADF 错误。如果这个数字每次都不一样，那么很可能有泄漏。

【讨论】：