性能文章>关于 /dev/null 差点直播吃鞋的一个小问题>

关于 /dev/null 差点直播吃鞋的一个小问题原创

8978412

我们的定时任务、异步 MQ 的 jar 包程序等都会使用 System.in.read() 等阻塞程序,防止程序退出,在本地测试一直都没有问题,直到有同学反馈,线上 Docker 环境中代码 System.in.read() 没有阻塞,执行到了后面的程序,简化过的代码如下所示。

public static void main(String[] args) throws IOException, InterruptedException {
    System.out.println("enter main....");
    // 启动定时任务
    startJobSchedule();
    
    System.out.println("before system in read....");
    System.in.read();
    System.out.println("after system in read....");
}

我瞄了一眼,觉得不可能,代码肯定会阻塞在 System.in.read(),然后说如果输出了 “after system in read…”,我直播吃鞋。结果一试,确实 System.in.read(); 退出了,执行了后续的语句,马上鞋就端上来,嗯,真香。

image.png

通过阅读这篇文章,你会了解到下面这些知识。

  • 进程与文件描述符 fd 的关系
  • /dev/null 文件的来龙去脉,读取写入的内核源码分析
  • 重定向本质
  • 管道概念初探

进程与文件描述符 fd

接下来我们先来看看进程与文件描述符 fd 之间的关系。一个进程启动以后,除了会分配堆、栈空间以外,还会默认分配三个文件描述符句柄:0 号标准输入(stdin)、1 号标准输出(stdout)、2 号错误输出(stderr),如下所示。

image.png

接下来了分析了一下开头的案例,System.in.read() 实际上是从 fd 为 0 的 stdin 读数据,我们将 System.in.read() 的返回值和读到的内容打印出来,经过实验,返回值为 -1,读到了 EOF。这比较奇怪,为什么去读 stdin 会返回 EOF 呢?

接下来去看 fd 为 0 的 stdin 到底指向了什么。在系统的 /proc/pid/fd 目录存储了进程所有打开的文件句柄,使用 ls 查看当前打开的句柄列表如下所示。

$ ls -l /proc/1/fd
total 0
lrwx------ 1 root root 64 43 17:13 0 -> /dev/null
l-wx------ 1 root root 64 43 17:13 1 -> pipe:[31508]
l-wx------ 1 root root 64 43 17:13 2 -> pipe:[31509]
l-wx------ 1 root root 64 43 17:13 3 -> /app/logs/gc.log
lr-x------ 1 root root 64 43 17:13 4 -> /jdk8/jre/lib/rt.jar
lr-x------ 1 root root 64 43 17:13 5 -> /app/system-in-read-1.0-SNAPSHOT.jar

可以看到为 0 的 fd 指向了 /dev/null。接下来看看 /dev/null 相关的知识。

/dev/null 文件

/dev/null 文件是什么

/dev/null 是一个特殊的设备文件,所有接收到的数据都会被丢弃。有人把 /dev/null 比喻为 “黑洞”,比较形象恰当。

image.png

除了丢弃所有的写入这个特性之外,从 /dev/null 读数据会立即返回 EOF,这就是造成前面 System.in.read() 调用直接退出的原因。

使用 stat 查看 /dev/null,输出的结果如下。

$ stat /dev/null
  File: ‘/dev/null’
  Size: 0         	Blocks: 0          IO Block: 4096   character special file
Device: 5h/5d	Inode: 6069        Links: 1     Device type: 1,3
Access: (0666/crw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:null_device_t:s0
Access: 2020-03-27 19:27:37.857000000 +0800
Modify: 2020-03-27 19:27:37.857000000 +0800
Change: 2020-03-27 19:27:37.857000000 +0800

$ who -b
         system boot  2020-03-27 19:27

可以看到 /dev/null 文件的大小为 0,创建、修改时间都与内核系统启动时间一致。它并不是一个磁盘文件,而是存在于内存中类型为 “character device file” 的文件。

所有的往这个文件的写入的数据会被丢弃,write 调用会是始终返回成功,这个特殊的文件不会被填满,也不能更改它的文件大小。

还有一个有趣的现象是使用 tail -f /dev/null 会永久阻塞,strace 命令输出结果精简如下所示。

$ strace tail -f /dev/null

open("/dev/null", O_RDONLY)             = 3
read(3, "", 8192)                       = 0
inotify_init()                          = 4
inotify_add_watch(4, "/dev/null", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1
read(4,

可以看到 tail -f 在执行过程中读取 /dev/null 的 read 调用返回了 0,表明它读取遇到了 EOF,随后 tail 使用 inotify_init 系统调用创建了一个 inotify 实例,这个实例监听了 /dev/null 文件的 IN_MODIFY、IN_ATTRIB、IN_DELETE_SELF、IN_DELETE_SELF 事件。这四个事件的含义如下。

  • IN_MODIFY:文件被修改
  • IN_ATTRIB:文件元数据修改
  • IN_DELETE_SELF:监听目录/文件被删除
  • IN_MOVE_SELF:监听目录/文件被移动
    随后阻塞等待这些事件的发生,因为 /dev/null 不会发生这些事件,所以 tail 命令之后会一直阻塞。

从源码角度看 /dev/null

内核处理 /dev/null 的逻辑在 https://github.com/torvalds/linux/blob/master/drivers/char/mem.c ,往 /dev/null 写入数据的代码在 write_null 函数,这个函数的源码如下所示。

static ssize_t write_null(struct file *file, const char __user *buf,
			  size_t count, loff_t *ppos)
{
	return count;
}

可以看到往 /dev/null 写入数据,内核没有做任何处理,只是返回了传入的 count 值。

读取的代码在 read_null 函数,这个函数的逻辑如下所示。

static ssize_t read_null(struct file *file, char __user *buf,
			 size_t count, loff_t *ppos)
{
	return 0;
}

可以看到,读取 /dev/null 会立即返回 0,表示 EOF。

至此,/dev/null 相关知识就介绍到这里。为什么本机测试没有出现问题?因为本机测试是用终端 terminal 去启动 jar 包,这样进程的 stdin 会被分配为键盘输入,在不输入字符的情况下,会始终阻塞。接下来我们来看看怎么在本地复现这个问题。

文件描述符与重定向

前面介绍的标准输入、标准输出、错误输出在描述符中的位置不会变化,但是它们的指向是可以改变的,我们用到的重定向操作符 > 和 < 就是用来重定向数据流的。为了修改上面进程的标准输入为 /dev/null,只需要使用 < 重定向符即可。修改前面的代码,加上 sleep 不让其退出。

public static void main(String[] args) throws IOException, InterruptedException {
    System.out.println("enter main....");
    byte[] buf = new byte[16];
    System.out.println("before system in read....");
    int length = System.in.read();
    System.out.println("len: " + length + "\t" + new String(buf));
    TimeUnit.DAYS.sleep(1);
}

打包运行,输出结果如下。

$ java -jar system-in-read-1.0-SNAPSHOT.jar < /dev/null

enter main....
before system in read....
len: -1

可以看到出现了与线上 docker 环境一样的现象,System.in.read() 没有阻塞,返回了 -1。

查看进程的 fd 列表如下所示:

$ ls -l  /proc/482/fd

lr-x------. 1 ya ya 64 43 20:00 0 -> /dev/null
lrwx------. 1 ya ya 64 43 20:00 1 -> /dev/pts/6
lrwx------. 1 ya ya 64 43 20:00 2 -> /dev/pts/6
lr-x------. 1 ya ya 64 43 20:00 3 -> /usr/local/jdk/jre/lib/rt.jar
lr-x------. 1 ya ya 64 43 20:00 4 -> /home/ya/system-in-read-1.0-SNAPSHOT.jar

可以看到此时的标准输入已经被替换为了 /dev/null,System.in.read() 调用时读取标准输入会先来查这个文件描述符列表,看 0 号描述符指向的是哪条数据流,再从这个数据流里读取数据。

image.png

上面的例子重定向了标准输入,标准输出和标准错误输出也是可以用类似的方式重定向。

  • 1> 或者 > 重定向标准输出
  • 2> 重定向标准错误输出
    或者可以组合使用:
java -jar system-in-read-1.0-SNAPSHOT.jar </dev/null > stdout.out 2> stderr.out

$ ls -l /proc/2629/fd

lr-x------. 1 ya ya 64 43 20:35 0 -> /dev/null
l-wx------. 1 ya ya 64 43 20:35 1 -> /home/ya/stdout.out
l-wx------. 1 ya ya 64 43 20:35 2 -> /home/ya/stderr.out

可以看到这次 fd 为 0、1、2 的文件描述符都被替换了。

shell 脚本中经常看到的 2>&1 是什么意思

拆解来看,2> 表示重定向 stderr ,&1 表示 stdout,连起来的含义就是将标准错误输出 stderr 改写为标准输出 stdout 相同的输出方式。比如将标准输出和标准错误输出都重定向到文件可以这么写。

cat foo.txt > output.txt 2>&1

接下来继续看文件描述符与管道相关的概念。

管道

管道是一个单向的数据流,我们在命令行中经常会用到管道来连接两条命令,以下面的命令为例。

nc -l 9090 | grep "hello" | wc -l

运行上面的命令,实际上的执行过程如下

  • 命令行创建的 zsh 进程
  • zsh 进程启动了 nc -l 9090 进程
  • zsh 进程启动了 grep 进程,同时将 nc 进程的标准输出通过管道的方式连接到 - grep 进程的标准输入
  • zsh 进程启动了 wc 进程,同时将 grep 进程的标准输出通过管道的方式连接到 - wc 进程的标准输入
    他们的进程关系如下所示。
  PID TTY      STAT   TIME COMMAND
23714 ?        Ss     0:00  \_ sshd: ya [priv]
23717 ?        S      0:00  |   \_ sshd: ya@pts/5
23718 pts/5    Ss     0:00  |       \_ -zsh
 4812 pts/5    S+     0:00  |           \_ nc -l 9090
 4813 pts/5    S+     0:00  |           \_ grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exc
 4814 pts/5    S+     0:00  |           \_ wc -l

查看 nc 和 grep 两个进程的文件描述符列表如下。

$ ls -l /proc/pid_of_nc/fd

lrwx------. 1 ya ya 64 43 21:22 0 -> /dev/pts/5
l-wx------. 1 ya ya 64 43 21:22 1 -> pipe:[3852257]
lrwx------. 1 ya ya 64 43 21:17 2 -> /dev/pts/5


$ ls -l /proc/pid_of_grep/fd

lr-x------. 1 ya ya 64 43 21:22 0 -> pipe:[3852257]
l-wx------. 1 ya ya 64 43 21:22 1 -> pipe:[3852259]
lrwx------. 1 ya ya 64 43 21:17 2 -> /dev/pts/5

$ ls -l /proc/pid_of_wc/fd

lr-x------. 1 ya ya 64 43 21:22 0 -> pipe:[3852259]
lrwx------. 1 ya ya 64 43 21:22 1 -> /dev/pts/5
lrwx------. 1 ya ya 64 43 21:17 2 -> /dev/pts/5

关系如下图所示。

image.png

在 linux 中,创建管道的函数是 pipe,常见的创建管道的方式如下所示。

int fd[2];
if (pipe(fd) < 0) {
    printf("%s\n", "pipe error");
    exit(1);
}

pipe 函数创建了一个管道,同时返回了两个文件描述符,fd[0] 用来从管道读数据,fd[1] 用来向管道写数据,接下来我们来看一段代码,看下父子进程如何通过管道来进行通信。

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

#define  BUF_SIZE 20
int main() {
  int fd[2];
  if (pipe(fd) < 0) {
    printf("%s\n", "pipe error");
    exit(1);
  }
  int pid;
  if ((pid = fork()) < 0) {
    printf("%s\n", "fork error");
    exit(1);
  }

  // child process
  if (pid == 0) {
    close(fd[0]); // 关闭子进程的读
    while (1) {
      int n = write(fd[1], "hello from child\n", 18);
      if (n < 0) {
        printf("write eof\n");
        exit(1);
      }
      sleep(1);
    }
  }

  char buf[BUF_SIZE];
  // parent process
  if (pid > 0) {
    close(fd[1]); // 关闭父进程的写
    while (1) {
      int n = read(fd[0], buf, BUF_SIZE);
      if (n <= 0) {
        printf("read error\n");
        exit(1);
      }
      printf("read from parent: %s", buf);
      sleep(1);
    }
  }
  return 0;
}

执行上面的代码,就可以看到从子进程写入的字符串,在父进程中可以读取并显示在终端中了。

$ ./pipe_test
read from parent: hello from child
read from parent: hello from child
read from parent: hello from child
read from parent: hello from child
read from parent: hello from child

docker 与 stdin

如果想让 docker 进程的 stdin 变为键盘终端,可以用 -it 选项启动 docker run。运行镜像以后,重新查看进程打开的文件描述符列表,可以看到 stdin、stdout、stderr 都已经发生了变化,如下所示。

$ docker exec -it 5fe22fbffe81 ls -l /proc/1/fd

total 0
lrwx------ 1 root root 64 45 23:20 0 -> /dev/pts/0
lrwx------ 1 root root 64 45 23:20 1 -> /dev/pts/0
lrwx------ 1 root root 64 45 23:20 2 -> /dev/pts/0

java 进程也阻塞在了 System.in.read() 调用上。

小结

这篇文章从一个小例子介绍了进程相关的三个基础文件描述符:stdin、stdout、stderr,以及这三个文件描述符如何进行重定向。顺带介绍了一下管道相关的概念,好了,鞋吃饱了,睡觉。

点赞收藏
分类:标签:
挖坑的张师傅

机械工业出版社《深入理解 JVM 字节码》作者,掘金小册作者《JVM 字节码从入门到精通》、《深入理解TCP 协议》作者,Vim 死忠粉、Kotlin&Go 爱好者、能抓一手好包、喜欢底层技术和分享。微信公众号:张师傅的博客(shifuzhang01)

请先登录,查看4条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

随机一门技术分享之Netty

随机一门技术分享之Netty

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

12
4