1）为了得到打开的文件描述符的总数，是否可以循环使用/proc ？ 我使用了以下dirs：
/proc/PID/fd/* /proc/PID/maps /proc/PID/cwd /proc/PID/root /proc/PID/exe
2）数字不同于lsof | wc -l lsof | wc -l和cat /proc/sys/fs/file-nr
3）加载dynamic链接库和当前工作目录可以计为打开的文件描述符？ 用C for Linux实现所有打开的文件描述符
你如何计算这取决于你感兴趣的信息。
浏览/proc/PID/fd/*会给你打开的文件描述符的数量。 但是，需要注意的是，两个进程可能实际上共享一个文件描述符，如果fork，那么子进程会从其父进程继承文件描述符，然后此方法将对其进行两次计数，每个进程计数一次。
/proc/PID/maps将向您显示进程的内存映射，其中可以包括加载的可执行文件本身和动态链接的库，但也包括与堆，堆栈， vdso部分是内核导出的虚拟共享对象，依此类推。
lsof将列出文件可以被使用的各种方式，其中不仅包括文件描述符， 它还包含可执行文件和共享库，但不包括与堆栈，堆， vdso部分等/proc/PID/maps中显示的文件不相对应的内存区域。
/proc/sys/fs/file-nr会报告打开的内核文件句柄的数量。 内核文件句柄不同于文件描述符; 可以有多个文件描述符打开指向相同的文件句柄，例如通过调用dup或dup2 。
这些差异解释了为什么你从这些不同的计数方式得到不同的数字。 问题是，你使用这个计数的目的是什么？ 这将有助于回答您实际使用哪种计数方式。
1）否，但是你的第二个问题就是建立一个打开的文件描述符，你似乎感到困惑
2）参见http://codingtragedy.blogspot.com/2015/04/nofile-ulimit-n-rlimitnofile-most.html – 虽然它解释了一个似乎不相关的资源限制的处理，但它也解释了文件描述符和一个你最想要的“结构文件”，它甚至涵盖了你的使用方法。
3）同样，你不清楚你的实际问题。 当前工作目录不是一个文件描述符，只是用一个inode来表示。 一个进程可能会或不会为链接的库保留fd，但映射本身占用一个“结构文件”。