Linux进程间通信？
进程间通信支持进程之间的通信，Linux支持进程间的多种通信机制，包含信号量、共享内存、消息
队列、管道、UNIX域套接字等，这些机制可协助多个进程、多资源的互斥访问、进程间的同步和消息传
递。在实际的Linux应用中，人们更多地趋向于使用UNIX域套接字，而不是System V IPC中的消息队列等
机制。Android内核则新增了Binder进程间通信方式。
Linux内核5个组成部分之间的依赖关系如下。
·进程调度与内存管理之间的关系：这两个子系统互相依赖。在多程序环境下，程序要运行，则必须
为之创建进程，而创建进程的第一件事情，就是将程序和数据装入内存。
·进程间通信与内存管理的关系：进程间通信子系统要依赖内存管理支持共享内存通信机制，这种机
制允许两个进程除了拥有自己的私有空间之外，还可以存取共同的内存区域。
·虚拟文件系统与网络接口之间的关系：虚拟文件系统利用网络接口支持网络文件系统（NFS），也
利用内存管理支持RAMDISK设备。
·内存管理与虚拟文件系统之间的关系：内存管理利用虚拟文件系统支持交换，交换进程定期由调度
程序调度，这也是内存管理依赖于进程调度的原因。当一个进程存取的内存映射被换出时，内存管理向虚
拟文件系统发出请求，同时，挂起当前正在运行的进程。
除了这些依赖关系外，内核中的所有子系统还要依赖于一些共同的资源。这些资源包括所有子系统都
用到的API，如分配和释放内存空间的函数、输出警告或错误消息的函数及系统提供的调试接口等。
Linux进程间通信
linux下进程间通信的几种主要手段简介： 一般文件的I/O函数都可以用于管道，如close、read、write等等。 实例1：用于shell 管道可用于输入输出重定向，它将一个命令的输出直接定向到另一个命令的输入。比如，当在某个shell程序（Bourne shell或C shell等）键入who│wc -l后，相应shell程序将创建who以及wc两个进程和这两个进程间的管道。 实例二：用于具有亲缘关系的进程间通信 管道的主要局限性正体现在它的特点上： 有名管道的创建 小结： 管道常用于两个方面：（1）在shell中时常会用到管道（作为输入输入的重定向），在这种应用方式下，管道的创建对于用户来说是透明的；（2）用于具有亲缘关系的进程间通信，用户自己创建管道，并完成读写操作。 FIFO可以说是管道的推广，克服了管道无名字的限制，使得无亲缘关系的进程同样可以采用先进先出的通信机制进行通信。 管道和FIFO的数据是字节流，应用程序之间必须事先确定特定的传输"协议"，采用传播具有特定意义的消息。 要灵活应用管道及FIFO，理解它们的读写规则是关键。 信号生命周期 信号是进程间通信机制中唯一的异步通信机制，可以看作是异步通知，通知接收信号的进程有哪些事情发生了。信号机制经过POSIX实时扩展后，功能更加强大，除了基本通知功能外，还可以传递附加信息。 可以从两个不同的分类角度对信号进行分类：（1）可靠性方面：可靠信号与不可靠信号；（2）与时间的关系上：实时信号与非实时信号。 (1) 可靠信号与不可靠信号 不可靠信号 ：Linux下的不可靠信号问题主要指的是信号可能丢失。 可靠信号 ：信号值位于SIGRTMIN和SIGRTMAX之间的信号都是可靠信号，可靠信号克服了信号可能丢失的问题。Linux在支持新版本的信号安装函数sigation（）以及信号发送函数sigqueue()的同时，仍然支持早期的signal（）信号安装函数，支持信号发送函数kill()。 对于目前linux的两个信号安装函数:signal()及sigaction()来说，它们都不能把SIGRTMIN以前的信号变成可靠信号（都不支持排队，仍有可能丢失，仍然是不可靠信号），而且对SIGRTMIN以后的信号都支持排队。这两个函数的最大区别在于，经过sigaction安装的信号都能传递信息给信号处理函数（对所有信号这一点都成立），而经过signal安装的信号却不能向信号处理函数传递信息。对于信号发送函数来说也是一样的。 (2) 实时信号与非实时信号 前32种信号已经有了预定义值，每个信号有了确定的用途及含义，并且每种信号都有各自的缺省动作。如按键盘的CTRL ^C时，会产生SIGINT信号，对该信号的默认反应就是进程终止。后32个信号表示实时信号，等同于前面阐述的可靠信号。这保证了发送的多个实时信号都被接收。实时信号是POSIX标准的一部分，可用于应用进程。非实时信号都不支持排队，都是不可靠信号；实时信号都支持排队，都是可靠信号。 发送信号的主要函数有：kill()、raise()、 sigqueue()、alarm()、setitimer()以及abort()。 调用成功返回 0；否则，返回 -1。 sigqueue()是比较新的发送信号系统调用，主要是针对实时信号提出的（当然也支持前32种），支持信号带有参数，与函数sigaction()配合使用。 sigqueue的第一个参数是指定接收信号的进程ID，第二个参数确定即将发送的信号，第三个参数是一个联合数据结构union sigval，指定了信号传递的参数，即通常所说的4字节值。 sigqueue()比kill()传递了更多的附加信息，但sigqueue()只能向一个进程发送信号。sigqueue()比kill()传递了更多的附加信息，但sigqueue()只能向一个进程发送信号。 inux主要有两个函数实现信号的安装： signal() 、 sigaction() 。其中signal()在可靠信号系统调用的基础上实现, 是库函数。它只有两个参数，不支持信号传递信息，主要是用于前32种非实时信号的安装；而sigaction()是较新的函数（由两个系统调用实现：sys_signal以及sys_rt_sigaction），有三个参数，支持信号传递信息，主要用来与 sigqueue() 系统调用配合使用，当然，sigaction()同样支持非实时信号的安装。sigaction()优于signal()主要体现在支持信号带有参数。 消息队列就是一个消息的链表。可以把消息看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。消息队列是随内核持续的 消息队列的内核持续性要求每个消息队列都在系统范围内对应唯一的键值，所以，要获得一个消息队列的描述字，只需提供该消息队列的键值即可； 消息队列与管道以及有名管道相比，具有更大的灵活性，首先，它提供有格式字节流，有利于减少开发人员的工作量；其次，消息具有类型，在实际应用中，可作为优先级使用。这两点是管道以及有名管道所不能比的。同样，消息队列可以在几个进程间复用，而不管这几个进程是否具有亲缘关系，这一点与有名管道很相似；但消息队列是随内核持续的，与有名管道（随进程持续）相比，生命力更强，应用空间更大。 信号灯与其他进程间通信方式不大相同，它主要提供对进程间共享资源访问控制机制。相当于内存中的标志，进程可以根据它判定是否能够访问某些共享资源，同时，进程也可以修改该标志。除了用于访问控制外，还可用于进程同步。信号灯有以下两种类型： int semop(int semid, struct sembuf *sops, unsigned nsops); semid是信号灯集ID，sops指向数组的每一个sembuf结构都刻画一个在特定信号灯上的操作。 int semctl(int semid，int semnum，int cmd，union semun arg) 该系统调用实现对信号灯的各种控制操作，参数semid指定信号灯集，参数cmd指定具体的操作类型；参数semnum指定对哪个信号灯操作，只对几个特殊的cmd操作有意义；arg用于设置或返回信号灯信息。 进程间需要共享的数据被放在一个叫做IPC共享内存区域的地方，所有需要访问该共享区域的进程都要把该共享区域映射到本进程的地址空间中去。系统V共享内存通过shmget获得或创建一个IPC共享内存区域，并返回相应的标识符。内核在保证shmget获得或创建一个共享内存区，初始化该共享内存区相应的shmid_kernel结构注同时，还将在特殊文件系统shm中，创建并打开一个同名文件，并在内存中建立起该文件的相应dentry及inode结构，新打开的文件不属于任何一个进程（任何进程都可以访问该共享内存区）。所有这一切都是系统调用shmget完成的。 shmget（）用来获得共享内存区域的ID，如果不存在指定的共享区域就创建相应的区域。shmat()把共享内存区域映射到调用进程的地址空间中去，这样，进程就可以方便地对共享区域进行访问操作。shmdt()调用用来解除进程对共享内存区域的映射。shmctl实现对共享内存区域的控制操作。这里我们不对这些系统调用作具体的介绍，读者可参考相应的手册页面，后面的范例中将给出它们的调用方法。 注：shmget的内部实现包含了许多重要的系统V共享内存机制；shmat在把共享内存区域映射到进程空间时，并不真正改变进程的页表。当进程第一次访问内存映射区域访问时，会因为没有物理页表的分配而导致一个缺页异常，然后内核再根据相应的存储管理机制为共享内存映射区域分配相应的页表。
文件描述符是什么
问题一：文件描述符和文件指针的区别 文件描述符：在linux系统中打开文件就会获得文件描述符，它是个很小的正整数。每个进程在PCB（Process Control Block）中保存着一份文件描述符表，文件描述符就是这个表的索引，每个表项都有一个指向已打开文件的指针。
文件指针：C语言中使用文件指针做为I/O的句柄。文件指针指向进程用户区中的一个被称为FILE结构的数据结构。FILE结构包括一个缓冲区和一个文件描述符。而文件描述符是文件描述符表的一个索引，因此从某种意义上说文件指针就是句柄的句柄（在Windows系统上，文件描述符被称作文件句柄）。
问题二：谁能解释一下文件描述符标志？ 文件描述符非负整数打现存文件或新建文件内核返文件描述符读写文件需要使用文件描述符指定待读写文件 习惯标准输入（standard input）文件描述符 0标准输（standard output） 1标准错误（standard error） 2尽管种习惯并非 Unix 内核特性些 shell 应用程序都使用种习惯内核遵循种习惯应用程序能使用 POSIX 定义 STDIN_FILENO、STDOUT_FILENO STDERR_FILENO 代替 0、1、2三符号量定义位于文件 unistd.h 文件描述符效范围 0 OPEN_MAX般说每进程打 64 文件（0 ― 63）于 FreeBSD 5.2.1、Mac OS X 10.3 Solaris 9 说每进程打文件少取决于系统内存int 及系统管理员设定限制
问题三：文件描述符的定义数量 如何在不同平台上定义文件描述符的数量文件描述符极限以及可分配给进程的最大大小由资源限制来定义。这些值应当按照在WebLogicServer文档中建议的、特定于操作系统的文件描述符值来设置：对于WLS8.1：调整硬件、操作系统和网络性能对于WLS7.0：调整硬件、操作系统和网络性能对于WLS6.1：调整硬件、操作系统和网络性能Unix和Linux都有文件描述符。不过，二者的主要区别在于如何设置文件描述符的硬极限值、缺省值和配置过程。Solaris/usr/bin/ulimit实用程序定义允许单个进程使用的文件描述符的数量。它的最大值在rlim_fd_max中定义，在缺省情况下，它设置为65,536。只有root用户才能修改这些内核值。Linux管理用户可以在etc/security/limits.conf配置文件中设置他们的文件描述符极限，如下例所示。softnofile1024hardnofile4096系统级文件描述符极限还可以通过将以下三行添加到/etc/rc.d/rc.local启动脚本中来设置：#Increasesystem-widefiledescriptorlimit.echo4096>/proc/sys/fs/file-maxecho16384>/proc/sys/fs/inode-maxWindows在Windows操作系统上，文件描述符被称作文件句柄。在Windows2000服务器上，打开文件的句柄极限设置为16,384。此数量可以在任务管理器的性能摘要中监视。HP-UXnfile定义打开文件的最大数量。此值通常由以下公式来确定：((NPROC*2)+1000)，其中NPROC通常为：((MAXUSERS*5)+64)。如果MAXUSERS等于400，则经过计算得到此值为5128。通常可以将此值设高一些。maxfiles是每个进程的软文件极限，maxfiles_lim是每个进程的硬文件极限。AIX文件描述符极限在/etc/security/limits文件中设置，它的缺省值是2000。此极限可以通过ulimit命令或setrlimit子例程来更改。最大大小由OPEN_MAX常数来定义。
问题四：文件描述符可以是0吗 文件描述符是一个简单的整数，用以标明每一个被进程所打开的文件和socket。
第一个打开的文件是0，第二个是1，依此类推。Unix 操作系统通常给每个进程能打开的文件数量强加一个限制。更甚的是，unix 通常有一个系统级的限制。 os.chinauni
问题五：如何判断文件描述符在fd open 一个文件将返回一个文件描述符。 0 - 返回的文件描述符 就是已经打开的。 /proc/pid/fd 下面为该进程打开的文件描述符 如果我的回答没能帮助您，请继续追问。
问题六：Linux查看进程打开多少文件描述符命令 linux系统下查看进程打开文件在/proc下，对应每个进程有一个以进程号命名的目录，该目录下有一个fd目录，该目录下面的每个文件是一个符号连接，其文件名对应该进程占用的一个文件描述符，而连接指向的内容表示文件描述符对应的实际文件，有多少个文件描述符表示该进程打开了多少文件。
另外Linux
默认的进程打开文件上限是1024个，可以通过ulimit
-n查看。很多系统上限可以通过修改/etc/security/limits.conf文件改变，这个文件有详细的注释，对如何修改做了说明。如果希望
把所有用户的进程打开文件上限改为65536，可以加入下面两行
* soft nofile 65535
* hard nofile 65535
还可以只真对某个用户或某个组做修改，具体方法参见文件注释。修改后需要重新启动系统才能生效。
问题七：linux 文件描述符 3是什么？例如 0 1 2代表标准的输出输入和出错，但是3，4又是什么的呢？ 其他已经被打开的文件
问题八：文件描述符挂起是什么意思 具体操作，需要修改两处，并且需重新启动Linux服务器。首先SSH登录服务器，执行ulimit-a查看当前限制。这一步是可选，主要是看下限制，心里有数。第一处修改：vim/etc/security/limits.conf在文件尾部增加:*softnofile65535*hardno
问题九：有人了解java与linux文件描述符之间的关系吗 linux文件描述符？ 可以认为是linux下的任务管理中打开文件的索引表，是系统中使用的。。。。。。。java是一个平台、一种编程语言。。。。。。不知道要怎么比较了。
问题十：文件描述符fb和tcp连接数有什么关系 C10K的问题在上个世纪90年代就被提出来了。大概的意思是当用户数超过1万时，很多设计不良好的网络服务程序性能都将急剧下降、甚至瘫痪。并且，这个问题并不能通过升级硬件设备解决，是操作系统固有的问题，也就是说，如果你的服务器最高能支撑1000个并发，尽管你升级了计算能力高一倍的 cpu，内存再翻一番，硬盘转速在快一倍，也无法支撑2000个并发。
经典的网络编程模型有4个：
1. Serve one client with each thread/process, and use blocking I/O。即对每个客户都使用不同的线程或进程进行服务，在每个线程或进程中使用阻塞I/O。这是小程序和java常用的策略，对于交互式的应用也是常见的选择，这种策略很能难满足高性能程序的需求，好处是实现极其简单，容易实现复杂的交互逻辑。我们常用的Apache、ftpd等都是这种工作。
2. Serve many clients with single thread, and use nonblocking I/O and readiness notification。即对所有的客户使用单一一个线程或进程进行服务，在这个线程或进程里，采用异步IO的策略。这是经典模型，优点在于实现较简单，方便移植，也能提供足够的性能；缺点在于无法充分利用多CPU的资源。
3. Serve many clients with each thread, and use nonblocking I/O and readiness notification 对经典模型2的简单改进，仍然采用异步IO的策略，但对所有的客户使用多个线程或进程进行服务。缺点是容易在多线程并发上出bug，甚至某些OS不支持多线程进行readiness notification
4. Serve many clients with each thread, and use asynchronous I/O 在有AI/O支持的OS上，能提供相当高的性能。不过AI/O编程模型和经典模型差别相当大，基本上很难写出一个框架同时支持AI/O和经典模型。这个模型主要是用于window平台上。
理解文件描述符
在Linux操作系统中，可以将一切都看作是文件，包括普通文件，目录文件，字符设备文件（如键盘，鼠标...），块设备文件（如硬盘，光驱...），套接字等等，所有一切均抽象成文件，提供了统一的接口，方便应用程序调用
既然在Linux操作系统中，你将一切都抽象为了文件，那么对于一个打开的文件，我应用程序怎么对应上呢？
文件描述符应运而生
文件描述符：简称fd，当应用程序请求内核打开/新建一个文件时，内核会返回一个文件描述符用于对应这个打开/新建的文件，其fd本质上就是一个非负整数，读写文件也是需要使用这个文件描述符来指定待读写的文件的
操作系统的核心叫内核，是一个独立的软件
操作系统为每一个进程维护了一个文件描述符表，该表的索引值都从从0开始的，所以在不同的进程中可以看到相同的文件描述符，这种情况下相同的文件描述符可能指向同一个文件，也可能指向不同的文件，具体情况需要具体分析，下面用一张简图就可以很容易的明白了
通过上图可以看到，当不同进程中出现相同的文件描述符时，可能实际对应的文件并不是同一个，相反不同进程中不同的文件描述符也可可能对应同一个文件
文件描述符是一个重要的系统资源，理论上系统内存多大就应该可以打开多少个文件描述符，但是实际情况是，内核会有系统级限制，以及用户级限制（不让某一个应用程序进程消耗掉所有的文件资源，可以使用ulimit -n 查看）
进程 + 文件描述符ID确认，因为内核为每个进程都有一份其所属的文件描述符表
应用程序进程拿到的文件描述符ID == 进程文件描述符表的索引，通过索引拿到文件指针，指向系统级文件描述符表的文件偏移量，再通过文件偏移量找到inode指针，最终对应到真实的文件
最后说下套接字，套接字也是文件，当server端监听到有连接时，应用程序会请求内核创建Socket，Socket创建好后会返回一个文件描述符给应用程序，当有数据包过来网卡时，内核会通过数据包的源端口，源ip，目的端口等在内核维护的一个ipcb双向链表中找到对应的Socket，并将数据包赋值到该Socket的缓冲区，应用程序请求读取Socket中的数据时，内核就会将数据拷贝到应用程序的内存空间，从而完成读取Socket数据
这里提一下，操作系统针对不同的传输方式（TCP，UDP）会在内核中各自维护一个Socket双向链表，当数据包到达网卡时，会根据数据包的源端口，源ip，目的端口从对应的链表中找到其对应的Socket，并会将数据拷贝到Socket的缓冲区，等待应用程序读取
最后附上Linux中进程结构图
