2>&1到底是什么意思？

java -jar snapshot.jar > snapshot.log 2>&1 &

写Java的朋友一定对上面的命令很熟悉，相信大部分人都知道​​>​​​表示的是重定向，那么什么是重定向？​​2>&1​​又是什么意思？

要从根儿上说明这个问题，我们有必要好好理解一下「文件描述符」的概念。

文件描述符

什么是文件描述符

文件描述符（File descripter）就是一个整数，这个整数唯一标识了操作系统中某个被打开的“文件”。

文件与I/O

说到“文件”必然离不开I/O。

很多人搞不明白I/O到底应该怎么理解，字面上就是输入/输出罢了，但是站在不同角度，其表示的含义也不一样。

站在计算机的角度，I/O表示的是计算机与外界的交互，交互的对象是硬件设备，输入输出自然也指的是和硬件之间的输入输出。

站在程序的角度，I/O的含义更宽泛，操作系统与所有能被当作文件的对象之间的交互就是I/O。

Linux的哲学思想是「一切皆文件」，文件（file，例如foo.txt）、管道（pipe）、网络（socket），甚至打印机、显示器、磁盘以及命令行（terminal）都算是文件。

文件描述符标识的就是这些文件。

文件描述符这个术语通常出现在Unix或类Unix系统中，比如Linux、MacOS以及BSD等。

在Windows系统中，他有另外一个响当当（或者臭名昭著）的名字——句柄（File handle）。

文件描述符原理

进程私有文件描述符表

每个进程可以打开多个文件，所以每个进程都会有一个私有的文件描述符表（file descriptors table）。

注：下文称​​file descriptors table​​​中的每一个条目为​​file descriptor​​​，称​​file descriptor​​​中的整数为​​fd​​。

需要注意的是，每个进程的fd ​​0​​​，​​1​​​，​​2​​​已经被占用（下文会有解释），之后分配的每个进程的​​fd​​​从​​3​​开始。

进程级的描述符表的每一个条目记录了当前进程所有打开的文件的文件描述符，进程之间相互独立，例如一个进程使用了文件描述符​​99​​​，另一个进程也可以用​​99​​。

​​fd​​​只是个数字而已，操作系统肯定需要根据这个数字来找到实际对应的文件。换句话说，​​file descripter​​肯定指向了某个表示真实文件的数据结构，或者能够再次根据这个数据结构来找到真实文件。

这个数据结构就是「全局文件表」。

全局文件表

全局文件表(global file table)，顾名思义，就是所有进程共享的一个数据结构。

当用户进程向内核发起一个针对文件的​​system call​​​（比如​​open()​​）时，内核将

1. 允许进程访问；
2. 向全局文件表（global file table）中插入一个条目，并向进程返回一个指向该条目的一个​​file descriptor​​；
3. 进程将​​file descriptor​​​插入到​​file descriptors table​​​，并返回其在​​file descriptors table​​​中的下标，也就是​​fd​​。

其实，根据global file table并不能直接找到对应文件进行操作，还需要根据其中的指针找到inode table的数据结构，进而再找到最终文件。但是这个技术细节对我们认识文件描述符没有什么作用，于是按下不表了。

为什么需要文件描述符

进程进行系统调用的时候，内核为什么不直接返回指向文件的指针呢？反而多此一举加了个​​fd​​来引用文件。

原因是为了防止用户空间的程序随意读写操作系统内核的文件对象。

如果内核直接返回内核中文件对象的地址给进程，进程便可以绕过内核，肆意对该文件进行操作，这样一来用户空间和内核空间的划分便如同虚设。

有了文件描述符之后，由于global file table处于内核空间中，用户即使拥有​​fd​​​，也无法得到实际文件对象的地址，除非把​​fd​​作为系统调用的参数来使用，如此一来，控制权又回到了内核手中，也便达到了权限控制的目的。

标准输入/标准输出/标准错误

前面说到，进程的文件描述符表的前3项已经被默认使用了。

• ​​0​​：标准输入（stdin）
• ​​1​​：标准输出（stdout）
• ​​2​​：标准错误（stderr）

这些名词怎么理解？

我们在Java中使用​​new Scanner(System.in)​​​接收从键盘的输入，使用​​System.out.println()​​​向显示器写数据，对应C语言分别是​​scanf()​​​和​​printf()​​。

需要明确的是，函数并非直接使用键盘和显示器，而是使用了标准输入和标准输出。

说得再通俗一点就是，进程生来就有一个耳朵和两张嘴，耳朵用来接受​​标准输入​​​里的数据，一个嘴往​​标准输出​​​里边“说话”，另一张嘴往​​标准错误​​里边“吐槽”。

函数并不知道数据从哪里来，也不关心数据要到哪里去，它们只需要从​​标准输入​​​读数据，向​​标准输出​​​、​​标准错误​​中写数据就行了。

这就是抽象啊，朋友们！

默认情况下，操作系统会把所有键盘输入都发送到​​标准输入​​​，会把从​​标准输出​​​、​​标准错误​​中读到数据发送到显示器。

为了方便表示，下文不再将全局文件表画出，而是用一张表来简化表示文件描述符和数据流之间的对应关系。

接下来我们就可以解释文章开头提的问题了。

输入输出重定向

​​标准输入/输出/错误​​在描述表的位置虽然是固定的，但他们指向的数据流是可以改变的。

java -jar snapshot.jar > snapshot.log 2>&1 &

这条指令的意思就是将​​snapshot.jar​​​程序用​​>​​​运算符重定向标准输出，由原本的指向显示器改为​​snapshot.log​​文件。

​​2>​​​是用来重定向标准错误，因为​​标准错误​​​在描述符表中的​​fd​​​就是​​2​​​，同样，其实重定向标准输出也可以表示为​​1>​​​，不过一般简写为​​>​​。

​​标准错误​​​和​​标准输出​​​可以重定向到同一个地方，比如指令中的​​&1​​​表示的就是​​标准输出​​​，​​2>&1​​​的含义就是重定向标准错误到​​标准输出​​表示的数据流中。

完！