博客访问： 2402189
博文数量： 167
博客积分： 3918
博客等级： 少校
技术积分： 8262
注册时间：
个人微薄： /manuscola
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： LINUX
前两天我们QA发现了一个比较有意思的bug，我细细分析一下，发现多个进程卡死在一个·配置文件上。简单的说，我们为了防止多个进程同时写同一个配置文件，将文件格式破坏，我们用了flock，对于写打开，同时调用flock 系统调用，LOCK_EX方式。当然了由于持有锁，就必须临界区要小，写完之后，尽量释放，持有锁的期间不要有time cost high 的操作，否则，会有其他进程获取不到文件锁，活活饿死。
这个bug比较有意思的地方是，大家都等锁的原因调用那个了一个python脚本，而这个脚本并不需要操作配置文件，仅仅是因为父进程system函数调用python脚本之前，没有关闭文件释放锁，导致python脚本很无辜的持有了这本锁，而python偏偏是个time cost high的操作，这就真是急中风偏偏遇到了慢郎中，外围一群进程焦急地等待这把锁，而python进程却占着毛坑不那啥，呵呵。
我们知道，linux存在强制锁（mandatory lock）和劝告锁（advisory lock）。所谓强制锁，比较好理解，就是你家大门上的那把锁，最要命的是只有一把钥匙，只有一个进程可以操作。所谓劝告锁，本质是一种协议，你访问文件前，先检查锁，这时候锁才其作用，如果你不那么kind，不管三七二十一，就要读写，那么劝告锁没有任何的作用。而遵守协议，读写前先检查锁的那些进程，叫做合作进程。我们代码用的是flock这种劝告锁。
Linux实现了POSIX规定的基于fcntl系统调用文件加锁机制，同时LINUX还支持BSD 变体的flock系统调用实现的劝告锁，当然system V变体的lockf也支持，大家可以自行查找手册。对于fcntl这个系统调用，大家可以阅读Stevens大神的UNIX网络编程卷2进程间通信，讲解的非常好。我的重点是flock。
flock的应用层接口如下
int flock(int fd, int operation);
其中fd是系统调用open返回的文件描述符，operation的选项有：
LOCK_SH ：共享锁
LOCK_EX ：排他锁或者独占锁
LOCK_UN :解锁。&
事实上Linux内核也实现了LOCK_MAND选项，所然manual中没有提到。这种情况我们不讨论。
注意了，flock系统调用实现的FL_FLOCK类型的锁，本质是一种劝告锁，只有多个进程之间遵循要读写，先调锁的协议，才会生效。遵循协议的进程叫合作进程。
下面看一段代码：
int main()
char buf[128];
int fd = open("./tmp.txt",O_RDWR);
time(&ltime);
fprintf(stdout,"%s
I am the father process,pid is %d\n",ctime_r(&ltime,buf),getpid());
write(fd,"write by father\n",32);
sleep(50);
close(fd);
time(&ltime);
fprintf(stdout, "%s
father exit\n",ctime_r(&ltime,buf));
fprintf(stderr, "error happened in fork\n");
return -3;
当然了，执行前，tmp.txt是存在的。我们写打开了一个文件tmp.txt，同时通过flock系统调用，申请了一把FL_FLOCK类型的锁然后fork了一个子进程。50秒后，父进程退出，子进程变成孤儿，100秒后，子进程退出。现在的问题是，父进程死去，子进程活着的期间，子进程是否持有这把锁？
我们让事实说话。先启动一个./test 5秒后启动另一个./test
这是第一个test所在的终端：
root@manu:~/code/c/self/flock# ./test
6 23:53:29 2013
I got the lock
6 23:53:29 2013
I am the father process,pid is 5632
6 23:53:29 2013
I am the son process,pid is 5633,ppid = 5632
6 23:54:19 2013
father exit
root@manu:~/code/c/self/flock# Wed Feb
6 23:55:09 2013
这是第二个test所在的终端：
root@manu:~/code/c/self/flock#
root@manu:~/code/c/self/flock# ./test
6 23:55:09 2013
I got the lock
6 23:55:09 2013
I am the father process,pid is 5634
6 23:55:09 2013
I am the son process,pid is 5647,ppid = 5634
6 23:55:59 2013
father exit
root@manu:~/code/c/self/flock# Wed Feb
6 23:56:49 2013
我们看到了，直到子进程退出，第二个启动的test的进程才申请到了这把FL_FLOCK锁。换言之，子进程会继承父进程的打开的所有文件，并且继承那把FL_FLOCK锁，哪怕他并不真正的操作这个文件。
BUT WHY ！！！
内核层之fd的分配
对于一个进程而言，我们知道有一个进程可以打开多个文件，ulimit -a我们可以看到，默认最多打开1024个文件。 其中STDIN，STDOUT，STDERR是三个默认的，对应的文件描述符是0 ，1 ，2.进程用0 1 2 这种数字来表征对应的FILE，当然他们是特殊的文件，对于打开的某真正的文件，那么可能对应的fd 为4 ，操作系统是如何根据这个4找到对应的文件的呢？这是我们这个小节需要解决的问题。
struct task_struct {
struct files_struct *
struct files_struct {
struct fdtable __rcu *
spinlock_t file_lock ____cacheline_aligned_in_
unsigned long close_on_exec_init[1];
unsigned long open_fds_init[1];
struct file __rcu * fd_array[NR_OPEN_DEFAULT];
struct fdtable {
unsigned int max_
struct file __rcu **
/* current fd array */
unsigned long *close_on_
unsigned long *open_
struct rcu_
struct fdtable *
我给出了一陀数据结构，这些数据结构是进程和文件相关的数据结构，不要被吓倒，这部分的关系还是比较简单的，我们来看下，进程如何管理它打开的文件。真正的描述打开的文件信息的数据结构是:
struct file {
atomic_long_t
unsigned int
可以清楚的看到struct file 才是正主，记录文件了mode，当前读写的位置了，之类的信息。那么从进程，如何通过fd，找到这个对应的struct file的呢？这就用到了我们前面提到的一坨数据结构了。fdtable 是距离 file最近的数据结构，max_fds是目前支持的最多文件数。fd是一个file指针的指针，或者说file指针 数组的基地址，这个数组包含有max_fds个file指针。比如我们上面的C程序，
tmp.txt对应的文件描述符是3,那么如何找到3对应的struct file 呢？ 很简单
fdtable->fd[3]这个指针指向的就是tmp.txt对应的struct file。
手握进程的fdtable，就能找到某个数字对应的struct file，那么如何从进程找到fdtable这个结构呢，也简单啊：
task_struct---->struct files_struct *
---->struct fdtable __rcu *
task_struct有一个struct file_struct 类型的变量files，而file又有一个fdtable类型的成员变量fdt，那么给个文件描述符的数字（即open的返回值如3）我们就可以完成从task_struct找到对应的struct file。
struct fdtable 里面的close_on_exec和open_fds是干啥的呢，这两个是位图，每个bit标记对应位置上的文件描述符有没有分配出去。比如我们打开tmp.txt的时候，就去open_fds里面去查找，发现0位置出的bit为1,表示文件描述符0已经分配出去了，（of course，这个STDIN），1位置出的bit值也是1（of course，这是STDOUT），一路找来，发现第一个不是0的bit是3位置处，OK , 表示文件描述符3没有被占用，就将3作为open的返回值。
比较细心的看官可能要问了，这部所有的问题都解决了吗，为啥除了struct files_struct 除了一个struct fd_table指针，还有一个fd_table实例呢？这不多余吗？，还有其中的close_on_exec_init，open_fds_init都是神马玩意儿啊，成员变量fdt不是已经把事情都办得妥妥当当的了吗？ 如下
struct files_struct {
struct fdtable __rcu *
unsigned long close_on_exec_init[1];
unsigned long open_fds_init[1];
struct file __rcu * fd_array[NR_OPEN_DEFAULT];
其实fdt这个指针，一开始指向的是fdtable这个实例，fdt->open_fds指向的是open_fds_init，同理fdt->fd_array指向的就是files_struct中的fd_array。简单的说就是我家里有32个酒杯，如果来的客人少，那么直接用家里的32个酒杯就行了，很不幸，过一会第33个客人来了，那么家里的酒杯就不够了，我就给玄武饭店打了个电话，请帮我预留256个酒杯，我马上过去喝酒，然后我将所有的32个客人+新来的客人一起带到玄武饭店，用那里准备好的256个酒杯，当然暂时用不了这么多，但是我已经预先占下了。既然已经换了喝酒的地点，为了防止后来的客人找不到，必须将地点改为玄武饭店，就好像fdt不再指向files_struct 自带的fdtable，而指向新分配的数据结构。
进程创建之初，总是指向自家的那32个酒杯。代码中如何体现呢？
do_fork---->copy_process---->copy_files---->dup_fd
在dup_fd中如如下代码：
newf->next_fd = 0;
new_fdt = &newf->
new_fdt->max_fds = NR_OPEN_DEFAULT;
new_fdt->close_on_exec = newf->close_on_exec_
new_fdt->open_fds = newf->open_fds_
new_fdt->fd = &newf->fd_array[0];
new_fdt->next = NULL;
对于fork出来的子进程来说，要拷贝父进程打开的所有文件，就好像子进程也打开了文件一样：可以用lsof验证之：
root@manu:~/code/c/self/flock# ./test &
root@manu:~/code/c/self/flock# Fri Feb
8 00:03:29 2013
I got the lock
8 00:03:29 2013
I am the father process,pid is 6226
8 00:03:29 2013
I am the son process,pid is 6227,ppid = 6226
root@manu:~/code/c/self/flock# lsof -p 6226
TYPE DEVICE SIZE/OFF
5 /dev/pts/2
5 /dev/pts/2
5 /dev/pts/2
321 2359759 /home/manu/code/c/self/flock/tmp.txt
root@manu:~/code/c/self/flock# lsof -p 6226
TYPE DEVICE SIZE/OFF
5 /dev/pts/2
5 /dev/pts/2
5 /dev/pts/2
321 2359759 /home/manu/code/c/self/flock/tmp.txt
对于父进程宴请的宾客个数（打开的文件）比较多，超过了32个，那么子进程会判断父进程准备的最大酒杯数，如果超过了32,得，刚才白忙乎了，还的去申请新的酒杯。注意，只是struct file的指针被拷贝，父进程的bitmap被拷贝，真正的struct file这个比较大的结构体并没有被拷贝一份。
old_fds = old_fdt->
new_fds = new_fdt->
/*拷贝位图信息*/
memcpy(new_fdt->open_fds, old_fdt->open_fds, open_files / 8);
memcpy(new_fdt->close_on_exec, old_fdt->close_on_exec, open_files / 8);
/*拷贝打开的file对应的struct file指针*/
for (i = open_ i != 0; i--) {
struct file *f = *old_fds++;
get_file(f);/*增加文件的引用计数，多了一个进程持有该strcut file
* The fd may be claimed in the fd bitmap but not yet
* instantiated in the files array if a sibling thread
* is partway through open().
So make sure that this
* fd is available to the new process.
__clear_open_fd(open_files - i, new_fdt);
rcu_assign_pointer(*new_fds++, f);
深入理解Linux内核
深入linux内核架构
Linux kernel code 3.6.7
阅读(4773) | 评论(2) | 转发(2) |
相关热门文章
给主人留下些什么吧！~~
：你对问题总是阐述的那么细腻，很喜欢彬兄的博客
呵呵兄弟过奖了。我也是工作遇到问题，现学现卖。 |
你对问题总是阐述的那么细腻，很喜欢彬兄的博客
请登录后评论。Linux 中 fcntl()、lockf、flock 的区别 - 文章 - 伯乐在线
& Linux 中 fcntl()、lockf、flock 的区别
这三个函数的作用都是给文件加锁，那它们有什么区别呢？首先flock和fcntl是系统调用，而lockf是库函数。lockf实际上是fcntl的封装，所以lockf和fcntl的底层实现是一样的，对文件加锁的效果也是一样的。后面分析不同点时大多数情况是将fcntl和lockf放在一起的。下面首先看每个函数的使用，从使用的方式和效果来看各个函数的区别。
int flock(int fd, int operation);
// Apply or remove an advisory lock on the open file specified by fd，只是建议性锁
其中fd是系统调用open返回的文件描述符，operation的选项有：
LOCK_SH ：共享锁
LOCK_EX ：排他锁或者独占锁
LOCK_UN : 解锁。
LOCK_NB：非阻塞（与以上三种操作一起使用）
关于flock函数，首先要知道flock函数只能对整个文件上锁，而不能对文件的某一部分上锁，这是于fcntl/lockf的第一个重要区别，后者可以对文件的某个区域上锁。其次，flock只能产生劝告性锁。我们知道，linux存在强制锁（mandatory lock）和劝告锁（advisory lock）。所谓强制锁，比较好理解，就是你家大门上的那把锁，最要命的是只有一把钥匙，只有一个进程可以操作。所谓劝告锁，本质是一种协议，你访问文件前，先检查锁，这时候锁才其作用，如果你不那么kind，不管三七二十一，就要读写，那么劝告锁没有任何的作用。而遵守协议，读写前先检查锁的那些进程，叫做合作进程。再次，flock和fcntl/lockf的区别主要在fork和dup。
(1) flock创建的锁是和文件打开表项（struct file）相关联的，而不是fd。这就意味着复制文件fd（通过fork或者dup）后，那么通过这两个fd都可以操作这把锁（例如通过一个fd加锁，通过另一个fd可以释放锁），也就是说子进程继承父进程的锁。但是上锁过程中关闭其中一个fd，锁并不会释放（因为file结构并没有释放），只有关闭所有复制出的fd，锁才会释放。测试程序入程序一。
#include &stdio.h&
#include &unistd.h&
#include &stdlib.h&
#include &sys/file.h&
int main (int argc, char ** argv)
int fd1 = open("./tmp.txt",O_RDWR);
int fd2 = dup(fd1);
printf("fd1: %d, fd2: %d\n", fd1, fd2);
ret = flock(fd1,LOCK_EX);
printf("get lock1, ret: %d\n", ret);
ret = flock(fd2,LOCK_EX);
printf("get lock2, ret: %d\n", ret);
12345678910111213141516
#include &stdio.h&#include &unistd.h&#include &stdlib.h&#include &sys/file.h&int main (int argc, char ** argv){&&&&int ret;&&&&int fd1 = open("./tmp.txt",O_RDWR);&&&&int fd2 = dup(fd1);&&&&printf("fd1: %d, fd2: %d\n", fd1, fd2);&&&&ret = flock(fd1,LOCK_EX);&&&&printf("get lock1, ret: %d\n", ret);&&&&ret = flock(fd2,LOCK_EX);&&&&printf("get lock2, ret: %d\n", ret);&&&&return 0;}
运行结果如图，对fd1上锁，并不影响程序通过fd2上锁。对于父子进程，参考程序二。
#include &stdio.h&
#include &unistd.h&
#include &stdlib.h&
#include &sys/file.h&
int main (int argc, char ** argv)
int fd = open("./tmp.txt",O_RDWR);
if ((pid = fork()) == 0){
ret = flock(fd,LOCK_EX);
printf("chile get lock, fd: %d, ret: %d\n",fd, ret);
sleep(10);
printf("chile exit\n");
ret = flock(fd,LOCK_EX);
printf("parent get lock, fd: %d, ret: %d\n", fd, ret);
printf("parent exit\n");
123456789101112131415161718192021
#include &stdio.h&#include &unistd.h&#include &stdlib.h&#include &sys/file.h&int main (int argc, char ** argv){&&&&int ret;&&&&int pid;&&&&int fd = open("./tmp.txt",O_RDWR);&&&&if ((pid = fork()) == 0){&&&&&&&&ret = flock(fd,LOCK_EX);&&&&&&&&printf("chile get lock, fd: %d, ret: %d\n",fd, ret);&&&&&&&&sleep(10);&&&&&&&&printf("chile exit\n");&&&&&&&&exit(0);&&&&}&&&&ret = flock(fd,LOCK_EX);&&&&printf("parent get lock, fd: %d, ret: %d\n", fd, ret);&&&&printf("parent exit\n");&&&&return 0;}
运行结果如图，子进程持有锁，并不影响父进程通过相同的fd获取锁，反之亦然。
(2)使用open两次打开同一个文件，得到的两个fd是独立的（因为底层对应两个file对象），通过其中一个加锁，通过另一个无法解锁，并且在前一个解锁前也无法上锁。测试程序如程序三：
#include &stdio.h&
#include &unistd.h&
#include &stdlib.h&
#include &sys/file.h&
int main (int argc, char ** argv)
int fd1 = open("./tmp.txt",O_RDWR);
int fd2 = open("./tmp.txt",O_RDWR);
printf("fd1: %d, fd2: %d\n", fd1, fd2);
ret = flock(fd1,LOCK_EX);
printf("get lock1, ret: %d\n", ret);
ret = flock(fd2,LOCK_EX);
printf("get lock2, ret: %d\n", ret);
12345678910111213141516
#include &stdio.h&#include &unistd.h&#include &stdlib.h&#include &sys/file.h&int main (int argc, char ** argv){&&&&int ret;&&&&int fd1 = open("./tmp.txt",O_RDWR);&&&&int fd2 = open("./tmp.txt",O_RDWR);&&&&printf("fd1: %d, fd2: %d\n", fd1, fd2);&&&&ret = flock(fd1,LOCK_EX);&&&&printf("get lock1, ret: %d\n", ret);&&&&ret = flock(fd2,LOCK_EX);&&&&printf("get lock2, ret: %d\n", ret);&&&&return 0;}
结果如图，通过fd1获取锁后，无法再通过fd2获取锁。
(3) 使用exec后，文件锁的状态不变。
(4) flock不能再NFS文件系统上使用，如果要在NFS使用文件锁，请使用fcntl。
(5) flock锁可递归，即通过dup或者或者fork产生的两个fd，都可以加锁而不会产生死锁。
2. lockf与fcntl
int lockf(int fd, int cmd, off_t len);
fd为通过open返回的打开文件描述符。
cmd的取值为：
F_LOCK：给文件互斥加锁，若文件以被加锁，则会一直阻塞到锁被释放。
F_TLOCK：同F_LOCK，但若文件已被加锁，不会阻塞，而回返回错误。
F_ULOCK：解锁。
F_TEST：测试文件是否被上锁，若文件没被上锁则返回0，否则返回-1。
len：为从文件当前位置的起始要锁住的长度。
通过函数参数的功能，可以看出lockf只支持排他锁，不支持共享锁。
int fcntl(int fd, int cmd, ... /* arg */ );
struct flock {
short l_/* Type of lock: F_RDLCK, F_WRLCK, F_UNLCK */
short l_ /* How to interpret l_start: SEEK_SET, SEEK_CUR, SEEK_END */
/* Starting offset for lock */
/* Number of bytes to lock */
pid_t l_ /* PID of process blocking our lock (F_GETLK only) */
123456789101112
#include #include int fcntl(int fd, int cmd, ... /* arg */ );struct flock {... short l_type;/* Type of lock: F_RDLCK, F_WRLCK, F_UNLCK */short l_whence; /* How to interpret l_start: SEEK_SET, SEEK_CUR, SEEK_END */ off_t l_start;&& /* Starting offset for lock */ off_t l_len;&&&& /* Number of bytes to lock */ pid_t l_pid; /* PID of process blocking our lock (F_GETLK only) */ ...&&&&&&&&&& };
文件记录加锁相关的cmd 分三种：
F_SETLK：申请锁（读锁F_RDLCK，写锁F_WRLCK）或者释放所（F_UNLCK），但是如果kernel无法将锁授予本进程（被其他进程抢了先，占了锁），不傻等，返回error。
F_SETLKW：和F_SETLK几乎一样，唯一的区别，这厮是个死心眼的主儿，申请不到，就傻等。
F_GETLK：这个接口是获取锁的相关信息： 这个接口会修改我们传入的struct flock。
通过函数参数功能可以看出fcntl是功能最强大的，它既支持共享锁又支持排他锁，即可以锁住整个文件，又能只锁文件的某一部分。
下面看fcntl/lockf的特性：
(1) 上锁可递归，如果一个进程对一个文件区间已经有一把锁，后来进程又企图在同一区间再加一把锁，则新锁将替换老锁。
(2) 加读锁（共享锁）文件必须是读打开的，加写锁（排他锁）文件必须是写打开。
(3) 进程不能使用F_GETLK命令来测试它自己是否再文件的某一部分持有一把锁。F_GETLK命令定义说明，返回信息指示是否现存的锁阻止调用进程设置它自己的锁。因为，F_SETLK和F_SETLKW命令总是替换进程的现有锁，所以调用进程绝不会阻塞再自己持有的锁上，于是F_GETLK命令绝不会报告调用进程自己持有的锁。
(4) 进程终止时，他所建立的所有文件锁都会被释放，队医flock也是一样的。
(5) 任何时候关闭一个描述符时，则该进程通过这一描述符可以引用的文件上的任何一把锁都被释放（这些锁都是该进程设置的），这一点与flock不同。如：
fd1 = open(pathname, …);
lockf(fd1, F_LOCK, 0);
fd2 = dup(fd1);
close(fd2);
fd1 = open(pathname, …);lockf(fd1, F_LOCK, 0);fd2 = dup(fd1);close(fd2);
则在close(fd2)后，再fd1上设置的锁会被释放，如果将dup换为open，以打开另一描述符上的同一文件，则效果也一样。
fd1 = open(pathname, …);
lockf(fd1, F_LOCK, 0);
fd2 = open(pathname, …);
close(fd2);
fd1 = open(pathname, …);lockf(fd1, F_LOCK, 0);fd2 = open(pathname, …);close(fd2);
(6) 由fork产生的子进程不继承父进程所设置的锁，这点与flock也不同。
(7) 在执行exec后，新程序可以继承原程序的锁，这点和flock是相同的。（如果对fd设置了close-on-exec，则exec前会关闭fd，相应文件的锁也会被释放）。
(8) 支持强制性锁：对一个特定文件打开其设置组ID位(S_ISGID)，并关闭其组执行位(S_IXGRP)，则对该文件开启了强制性锁机制。再Linux中如果要使用强制性锁，则要在文件系统mount时，使用_omand打开该机制。
3. 两种锁的关系
那么flock和lockf/fcntl所上的锁有什么关系呢？答案时互不影响。测试程序如下：
#include &unistd.h&
#include &stdio.h&
#include &stdlib.h&
#include &sys/file.h&
int main(int argc, char **argv)
fd = open("./tmp.txt", O_RDWR);
ret = flock(fd, LOCK_EX);
printf("flock return ret : %d\n", ret);
ret = lockf(fd, F_LOCK, 0);
printf("lockf return ret: %d\n", ret);
sleep(100);
12345678910111213141516
#include &unistd.h&#include &stdio.h&#include &stdlib.h&#include &sys/file.h&int main(int argc, char **argv){&&&&int fd, ret;&&&&int pid;&&&&fd = open("./tmp.txt", O_RDWR);&&&&ret = flock(fd, LOCK_EX);&&&&printf("flock return ret : %d\n", ret);&&&&ret = lockf(fd, F_LOCK, 0);&&&&printf("lockf return ret: %d\n", ret);&&&&sleep(100);&&&&return 0;}
测试结果如下：
flock return ret : 0
lockf return ret: 0
可见flock的加锁，并不影响lockf的加锁。两外我们可以通过/proc/locks查看进程获取锁的状态。
$ps aux | grep a.out | grep -v grep
0:00 ./a.out
$sudo cat /proc/locks | grep 18849
WRITE : EOF
WRITE : EOF
我们可以看到/proc/locks下面有锁的信息：我现在分别叙述下含义：
1) POSIX FLOCK 这个比较明确，就是哪个类型的锁。flock系统调用产生的是FLOCK，fcntl调用F_SETLK，F_SETLKW或者lockf产生的是POSIX类型，有次可见两种调用产生的锁的类型是不同的；
2) ADVISORY表明是劝告锁；
3) WRITE顾名思义，是写锁，还有读锁；
4) 18849是持有锁的进程ID。当然对于flock这种类型的锁，会出现进程已经退出的状况。
5) 08:02:852674表示的对应磁盘文件的所在设备的主设备好，次设备号，还有文件对应的inode number。
6) 0表示的是所的其实位置
7) EOF表示的是结束位置。 这两个字段对fcntl类型比较有用，对flock来是总是0 和EOF。
打赏支持我写出更多好文章，谢谢！
打赏支持我写出更多好文章，谢谢！
关于作者：
可能感兴趣的话题
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线内容团队正试图以我们微薄的力量，把优秀的原创文章和译文分享给读者，为“快餐”添加一些“营养”元素。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2017 伯乐在线flock()&Linux下的文件锁
flock() 的函数原型如下所示：
int flock(int fd, int operation);
其中，参数 fd 表示文件描述符；参数 operation 指定要进行的锁操作，该参数的取值有如下几种：
LOCK_SH：表示要创建一个共享锁，在任意时间内，一个文件的共享锁可以被多个进程拥有；
LOCK_EX：表示创建一个排他锁，在任意时间内，一个文件的排他锁只能被一个进程拥有；
LOCK_UN：表示删除该进程创建的锁；
LOCK_MAND：它主要是用于共享模式强制锁，它可以与 LOCK_READ 或者 LOCK_WRITE
联合起来使用，从而表示是否允许并发的读操作或者并发的写操作；
通常情况下，如果加锁请求不能被立即满足，那么系统调用 flock()
会阻塞当前进程。比如，进程想要请求一个排他锁，但此时，已经由其他进程获取了这个锁，那么该进程将会被阻塞。如果想要在没有获得这个排他锁的情况下不阻塞该进程，可以将
LOCK_NB 和 LOCK_SH 或者 LOCK_EX 联合使用，那么系统就不会阻塞该进程。flock()
所加的锁会对整个文件起作用。
1. 对于文件的 close() 操作会使文件锁失效；
2. 同理，进程结束后文件锁失效；
3. flock() 的 LOCK_EX
是“劝告锁”，系统内核不会强制检查锁的状态，需要在代码中进行文件操作的地方显式检查才能生效。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。