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()锁应该互动，也有过在过去的分歧。现在，情况有所缓解， 大约
可以说

1. fcntl() 锁是最可靠的

在整个体系结构中，它们具有在共享文件系统上正常工作的最佳机会，例如NFS和CIFS挂载。

1. 通常，它lockf()被实现为“简写”fcntl()

另一种选择，如的“简写” flock()是可能的，但如今很少见。

1. fcntl()并且flock()具有不同的语义 继承和自动发布

fcntl()锁在上保留exec()，但在上不继承fork()。当拥有过程关闭引用同一文件的 任何 描述符时，将释放这些锁。

在Linux，FreeBSD和MAc OS X中，flock()锁与打开的文件描述符结合在一起：传递描述符也传递锁。（手册页指出
“该锁在文件上，而不在文件描述符上 。”这并不矛盾。这仅表示该锁 适用
于文件。它仍以这种方式耦合到描述符因此，如果多个进程flock()在flock()调用后从发起者那里获取了描述符，则多个进程可能同时在同一文件上具有相同的排他咨询锁。

文件锁定是令人惊讶的复杂问题。我个人仅坚持fcntl()锁定即可获得最佳结果。语义wrt。fcntl()锁不是最容易使用的锁，在某些情况下，坦率地说，这很令人生气；只是我发现它可以产生最佳-
最可靠，最便携，最不令人惊讶的结果。