为什么不能在python 锁定文件中聚集？注意变量的范围
大家好，关于为什么不能在python 锁定文件中聚集？注意变量的范围很多朋友都还不太明白，今天小编就来为大家分享关于的知识，希望对各位有所帮助！
在窗口中运行以下命令，其中--verbose会导致flock输出锁定文件的详细过程，-n表示non-block，即如果无法锁定文件，则进程会直接以non-退出零值而不是等待。可以看到是时候正常锁定这个文件了。
#flock --verbose -n test.lock bash -c 'echo lock ok; sleep 100'在窗口1中运行flock命令，成功
同时我也在另一个窗口中输入了这个命令，发现锁定失败，这符合我们的预期。
窗口2 中的相同集群命令失败。
为了查看文件锁的详细信息，我们使用lsof查看第一个窗口中flock进程打开的文件。可以看到test.lock文件的FD列中有一个W，表示整个文件受到了写锁。所以第二个窗口的羊群无法被锁定。
#lsof -p 17997lsof 显示窗口1中的flock进程已锁定文件
0x02 在python中使用flock
在Python中，您可以使用标准库中的fcntl.flock来锁定文件。我们首先尝试使用相同的方法来锁定文件。 python进程启动后，直接锁定/var/run/test.lock1文件。成功后运行主程序代码。
有问题的集群代码
然后我在两个窗口中运行代码，发现都能运行到主代码，说明文件没有被锁定！到底是怎么回事？
窗口1中的代码运行
窗口2中的代码运行
使用lsof 查看两个进程如何打开文件。奇怪的是没有找到/var/run/test.lock1！但程序日志显示它是打开的。
0x03 python使用引用计数进行GC,会自动关闭文件
当遇到这个奇怪的问题时，我们使用我们的工件strace 来跟踪系统调用。
#strace python3 tflock.py /tmp/aa 从strace的输出中，我们可以看到/var/run/test.lock1被打开，然后flock对其放置了互斥锁，然后将其关闭。
strace 显示文件在锁定后已关闭
看看我们的代码。没有调用close(fd)。为什么文件被关闭？
Python解释器自带GC，而且是引用计数GC。即当对象的引用计数为0时，自动释放。我们的fd 是在lockFile1 函数中定义的。当这个函数执行完毕后，它的作用域就不再多了，fd对应的打开文件引用计数就变成0了，它的资源就会被释放。对于打开的文件，释放过程中包含了对fd的close调用，这就是为什么代码中没有close(fd)，但文件已经被关闭了。
那么为什么当文件关闭时文件的锁就会消失呢？
man 2flock中有如下一段，当调用LOCK_UN并且所有fd都关闭时，flock会被释放。
此外，锁可以通过对任何这些重复文件描述符执行显式LOCK_UN 操作来释放，或者当所有此类文件描述符都已关闭时释放。
0x04 使用全局变量保持文件开启
知道原因后解决这个问题就比较简单了。由于函数中的局部变量在函数返回后就会消失，那么就可以使用全局变量了。
这样，当第二个窗口运行时，就会直接报BlockingIOError错误，并且无法锁定文件。
第二个窗口文件无法锁定
lsof显示第一个窗口中的python3进程成功锁定了文件。
第一个窗口成功锁定文件
用户评论
我一直以为 Python 的 `flock` 就用来加锁定文件的，看来我错了呀！这篇文章让我明白了原因，原来是这个锁机制作用在进程级别的共享内存上，而不是直接针对文件本身。还是得多学习啊...
有10位网友表示赞同！
作者解释得挺清楚的，以前我也遇到过这个问题，每次写完代码之后就报错误说已经被使用了，现在终于知道怎么解决啦！
有19位网友表示赞同！
这篇文章真是太有用了！我之前尝试用 `flock` 在多进程环境下处理文件时遇到了问题，这篇博客解决了我的疑惑。作者分析了 Python 里变量作用域的特点，也很清晰地解释了为什么 `flock` 对文件的锁定效果有限。
有18位网友表示赞同！
我倒是觉得这挺好的，直接针对文件进行锁定了会不会太局限，毕竟很多情况需要考虑进程间的协作呢！这样设计也更容易跨平台使用呀!
有6位网友表示赞同！
我觉得这个机制比较灵活，可以根据不同的需求选择适合的锁定方式。有些情况下，只是需要在同一进程内保证数据的同步性，而不用担心多进程竞态冲突，这时候直接用本地变量锁就足够了。如果真的是要在多个进程间共享数据并进行同步，就要考虑使用更高级别的 locking 机制。这篇文章很好的解释了这些概念
有12位网友表示赞同！
为什么 python 锁不住文件 我感觉没啥用啊！多线程 多进程 直接写共享内存 才是王道吧!
有12位网友表示赞同！
这篇文章说的太对了，在 Python 中要真正控制文件的访问权限的话，需要结合其他机制例如数据库或者更高级的锁机制。
有12位网友表示赞同！
文章很有见解，我以前一直以为 `flock` 就是用来锁定文件的万能钥匙，后来遇到类似的情况就懵逼了！感谢作者的详细解释，让我明白了很多知识点！
有16位网友表示赞同！
说的好，多线程、多进程开发中文件加锁确实需要慎重考虑。有些情况下直接修改变量并不会带来太大问题，这篇文章很好的解释了为什么这样设计。
有9位网友表示赞同！
这个解释真是太贴切了，我之前用 `flock` 经常遇到奇怪的问题，现在仔细想想都是作用域导致的！
有20位网友表示赞同！
我觉得这种机制很有意思，它考虑了不同场景下的需求，灵活度还是很高的。但对于一些特定场景来说，可能还是需要使用更高级别的锁机制来保证数据同步的可靠性，比如在高并发情况下。
有11位网友表示赞同！
我之前也遇到过类似的问题，尝试用 `flock` 加锁导致程序卡死的情况。现在看来是理解锁的机制不够深入导致的错误啊！这篇博文很有帮助！
有14位网友表示赞同！
文章说得非常透彻，解释变量作用域方面也很清楚易懂！对于新手来说，非常有用，能够更好地理解 Python 的底层工作原理，避免类似的问题发生。
有17位网友表示赞同！
这个机制挺好，但也有一定的局限性。如果在多进程环境下进行文件操作，`flock` 就无法直接解决问题了。需要结合其他锁机制才能保证数据一致性。
有15位网友表示赞同！
文章写的很好，很清晰的解释了Python中的 `flock` 锁以及作用域概念。 作为一名初学者，我受益匪浅！我会继续学习和探索更高级别的锁机制
有6位网友表示赞同！
我一直以为 `flock` 能锁住文件，结果发现并不像想象中那么强大！这个博客让我明白了问题的根源，也让我对Python的锁机制有了更深入的了解。
有17位网友表示赞同！
我觉得这个问题还是挺关键的，如果在多进程环境下处理文件，需要更加小心选择合适的锁机制，避免出现数据竞争问题导致程序崩溃
有20位网友表示赞同！