flock()和之间的实际区别在于
lockf()语义（关于关闭和传递的行为），在NFS和其他共享文件系统上的适用性以及咨询锁是否对其他使用
fcntl()锁的进程可见。
您正在使用的库仅具有根据当前平台选择所需语义的逻辑。
如果语义（行为优于描述符传递，派生等）是可以接受的，则在Linux中，您应该更喜欢
lockf()/
fcntl()locks而不是
flock()锁，这仅仅是因为前者适用于NFS等文件系统，而后者则不行。（在BSD和Mac OS
X上，我相信您需要显式使用
fcntl()来代替。）
在Linux中，
lockf()它只是的包装
fcntl()，而
flock()锁是分开的（并且仅适用于本地文件系统，不适用于2.6.12之前的内核上的NFS挂载）。也就是说，一个进程可以
flock()在文件上具有咨询排他锁，而另一个进程可以
fcntl()在同一文件上具有咨询排他锁。两者都是咨询锁，但它们不交互。
在Mac OS
X和FreeBSD上，
lockf()/
flock()/
fcntl()锁定全部交互，尽管建议开发人员仅使用应用程序中的一种接口。但是，只有
fcntl()锁才能在NFS挂载上工作（并且很明显，只有将NFS客户端和服务器都配置为支持记录锁，这在Web托管环境中很少见；这是某些Web（框架）开发人员头痛的巨大原因）
）。
POSIX没有明确规定如何
lockf()/
flock()/
fcntl()锁应该互动，也有过在过去的分歧。现在，情况有所缓解， 大约
可以说
fcntl()
锁是最可靠的
在整个体系结构中，它们具有在共享文件系统上正常工作的最佳机会，例如NFS和CIFS挂载。
- 通常，它
lockf()
被实现为“简写”fcntl()
另一种选择，如的“简写”
flock()是可能的，但如今很少见。
fcntl()
并且flock()
具有不同的语义 继承和自动发布
fcntl()锁在上保留
exec()，但在上不继承
fork()。当拥有过程关闭引用同一文件的 任何 描述符时，将释放这些锁。
在Linux，FreeBSD和MAc OS X中，
flock()锁与打开的文件描述符结合在一起：传递描述符也传递锁。（手册页指出
“该锁在文件上，而不在文件描述符上 。”这并不矛盾。这仅表示该锁 适用
于文件。它仍以这种方式耦合到描述符因此，如果多个进程
flock()在
flock()调用后从发起者那里获取了描述符，则多个进程可能同时在同一文件上具有相同的排他咨询锁。
文件锁定是令人惊讶的复杂问题。我个人仅坚持
fcntl()锁定即可获得最佳结果。语义wrt。
fcntl()锁不是最容易使用的锁，在某些情况下，坦率地说，这很令人生气；只是我发现它可以产生最佳-
最可靠，最便携，最不令人惊讶的结果。
