我懂你的疑惑——一开始我也觉得线程锁就是给多个抢资源的线程准备的，单线程用锁完全是多此一举对吧？但咱们仔细拆解你贴的这段代码，其实这里的锁作用和你想的不太一样，甚至可能是误用：

首先得纠正一个误区：线程锁不是只针对“多个非主线程”，主线程也是线程！如果子线程和主线程之间有共享资源需要同步，那也得用到锁。比如你代码里的shutdown全局变量，虽然Python里简单的全局变量读写是原子操作，但如果有更复杂的共享资源交互（比如主线程修改shutdown的同时子线程在判断），锁就能避免竞态问题。不过这段代码里的锁并没有直接保护shutdown，所以咱们接着看。

然后说回这段代码的锁用法——它其实有明显问题：你看，它在tLock.acquire()之后直接进入了一个无限while True循环去调用sock.recvfrom()，这意味着锁会被这个子线程一直持有，除非抛出异常才会释放。这完全违背了锁的使用原则：锁应该只在访问共享资源的「临界区」短暂持有，用完立刻释放。这段代码里的锁大概率是误用了——可能原作者误以为print操作需要同步，或者把recvfrom当成了需要保护的共享资源，但实际上单线程调用socket.recvfrom()根本不需要锁。

还有一种可能性：这段代码是从多线程场景简化过来的。比如原版本可能有多个接收线程同时抢socket资源，后来改成了单线程，但锁的代码没删掉；或者作者想预留扩展空间，以后要加更多线程的时候，不用再重新写锁的逻辑。

总结一下：单线程不是绝对不能用锁，但要分场景——要么是和主线程做同步，要么是代码有残留/误用，要么是为未来扩展做准备。但你贴的这段代码里的锁，确实属于使用不当的情况，持有时间太长反而会影响后续扩展。

内容的提问来源于stack exchange，提问作者hiyum