Python源码阅读——lru_cache Python源码全解析
阅读前提示：强烈建议开启手机的深色模式以获得更好的沉浸体验。本文章中图片均为深色模式（黑底白字）风格好久没做Python教学了，今天来带大家看一个Python内置库中的函数lru_cache。它的文档地址为：https://docs.python.org/zh-cn/3.14/library/functools.html#functools.lru_cache
首先简单地介绍一下这个函数。在某些时候，某个函数执行时耗时较长，但对于每个输入，总有相同的返回值，且这个函数不依赖，不修改外部状态。我们便可以借助lru_cache，用字典缓存函数每组输入参数对应的输出，将复杂的函数执行替换为简单的字典查找，以空间换时间。它既可以作为装饰器使用，又可以作为函数使用，作为函数使用时它返回一个装饰器。以下是一个简单的事例可以看到，第一次调用两个函数用的时间是1e-3量级，而接下来连续调用了10次这两个函数，外加一个for循环，时间量级仍然降低到了1e-6。另：lru_cache有一个少见但重要的typed参数。typed是布尔值，当其为True时，lru_cache的缓存将对数据类型敏感。比如这段代码，缓存会认为这两次传参不同。大家看下文的函数文档也能看懂502行~505行，类型检查和特殊情况处理，略过不提。506行的callable(maxsize)，这是第一个令人有疑问的点：maxsize不应该是一个整数吗，检查它是否可被调用，这是什么逻辑？前面提到过，lru_cache可以作为装饰器被直接使用。而如果你学过装饰器，你就应该知道，当用户用lru_cache直接装饰一个函数f时，装饰器将被自动传入一个参数f（即被装饰的函数）所以，第506行的目的是：判断lru_cache是否被直接作为装饰器使用第507行的注释也解释了上文的判断（注释翻译：用户函数是直接作为maxsize参数传递的）第508行，进行了一个简单的转化，将maxsize赋值给了user_function变量，将128赋值给了maxsize。从此我们也可以知道，在直接把lru_cache当做装饰器的情况下，maxsize将是128。第509行，欢迎来到今天的重点：_lru_cache_wrapper。它是一个工厂函数，专门负责生成一个带有缓存功能的包装函数（wrapper）。这个工厂函数的核心职责是根据maxsize的值来创建不同行为的包装函数，包装函数内部拥有缓存的查找，更新和淘汰。它的返回值是包装函数wrapper。另外，它还在包装函数内部添加了cache_info和cache_clear函数，供开发者们进行手动检查和优化。光是这么说大家大概率没什么感觉，让我们来看看源代码。这个函数的源代码一共有115行，我们会逐段拆分阅读这是这个超长函数的第一部分，主要是初始化的作用。这些变量等我们遇到了再详细地进行解释。现在先简单说明几个关键的变量sentinel直译为“哨兵”，在本函数中，用于指明缓存是否成功地从缓存字典中被读取了。下面分析时会详细解释hits和misses分别代表缓存命中和缓存未命中的次数，full代表缓存字典是否已经到达最大容量。cache是缓存字典。cache_get和cache_len的定义将LOAD_GLOBAL和LOAD_ATTR转换为了LOAD_FAST，加快运行速度。lock是可复入锁，用于确保接下来wrapper内在进行缓存相关操作时线程安全make_key函数负责将每一组函数传入参数，都打包成了一个唯一的，可哈希的对象，用于在缓存字典中进行查找操作。以下是部分重要源代码。具体的算法较为简单，大家可自己阅读。好了， 初始化的部分我们看完了，接下来看根据maxsize不同的值，wrapper分别是什么行为上面代码里提到的nonlocal关键字用法和global类似。但global声明该变量为全局变量，而nonlocal在嵌套函数中，说明变量属于外层函数的作用域（非全局），不了解也没事，不太影响读代码540行这个wrapper概括起来就一句话，maxsize为0，不进行缓存，直接调用用户函数接下来这段，也相对好懂一点。maxsize是None，即不限制缓存大小。552行尝试从缓存字典里读取之前存储过的返回值，这个操作如果读取失败会返回默认值sentinel那第554行的条件判断，result is not sentinel，如果这个条件为真，说明第553行读取到的结果不是sentinel，这代表着之前从缓存中查找到函数返回值的尝试已经成功了！所以增加缓存命中的次数，然后直接返回result557~560行是缓存未命中后的处理流程。如果缓存没有命中，那么将misses增加1，然后调用用户函数，随后将之前定义的key作为键，用户函数的返回值作为值，更新进字典里当看到这么长的代码时，笔者已经崩溃了……这篇文章到现在接近一千五百字，而且后面估计还要有一大堆东西。这一段又是纯算法内容，我自己还讲不明白。所以很抱歉，这里我只会详细讲一个点：582行，为什么要把调用用户函数的代码放在锁外在锁内部（即with lock代码块内部），其他线程想要执行自己的代码时会被阻塞在锁外部。而用户函数运行时间可能非常长，这会导致单一线程长期占用全部资源。本来GIL已经使多线程的速度降到很低了，现在好了，其他线程还得花大量时间等待响应。锁内的操作应该是快速（此处全都是赋值或字典相关的操作，不会长时间占用cpu），明确的。而耗时的或不确定的操作（用户函数是不确定的）应该放在锁外。至于用户函数会不会出现线程相关的问题，那就是用户的事了，这不归lru_cache管。然后其他代码实现的，是LRU（最近最少使用）算法，字典+双向链表，用于在缓存空间满时删除最旧的缓存，同时通过复用哨兵节点等技巧，优化了性能，避免了__del__不确定何时运行的问题。这部分内容设计非常巧妙，奈何笔者薄弱的算法功底，实在无法用文字清晰地解释清楚这种美好了， 不求甚解地看完了这个工厂函数，我们的任务完成大半了，接下来回归到lru_cache函数第510行，给wrapper动态附加了一个方法：cache_parameters。这个方法可以用于给外部查询装饰器的maxsize和typed的值。为什么要用lambda而不是直接给字典？这是因为lambda有延时求值的特性，它会等到被调用时才构造字典，从而节省时间。第511行，update_wrapper内部代码如下，这个函数很简单，看一下就行了核心逻辑在50~56行，我相信大家一看到这个for循环和WRAPPER_ASSIGNMENTS的定义，就知道这个函数的目的了：保留用户函数的元信息。防止在读用户函数元数据时错误读取lru_cache的元数据回到第511行，lru_cache直接装饰用户函数的路线就结束了。第516行，当502行的if成立时，由于if-elif的性质，会跳过所有elif（和else，虽然此处没有），直接到达第515行。换句话说，第515行以下的代码，只会在用户将lru_cache当做一个返回装饰器的函数使用时才会执行那么很显然，这个decorating_function就是要返回的装饰器。517~519行和509~511行代码完全一样，不再赘述。最后在521行，返回这个装饰器，整体逻辑结束那么回过头看，从这次的源代码阅读之路上，我们能学到哪些信息？lru_cache专门管理用户两种不同的调用方法，而_lru_cache_wrapper作为工厂函数，专门创造包装函数wrapper，在wrapper内部再处理具体的缓存增删查逻辑。而不是将所有的逻辑全部写在一个巨大的函数内第504行，连maxsize是负数的情况都考虑了。_lru_cache_wrapper对线程安全问题做的防御性编程更是完美。这两行代码的目的，仅仅是为了优化函数查找（不是调用！）的速度。_lru_cache_wrapper里面十几行的长段注释来解释这些代码到底干什么，足以证明在不理解的情况下，读这些代码有多困难你以为是Python官方不重视可读性？readability counts都写进Python之禅里面了。是为了速度和效率而被迫“优化”到难以理解的程度的Python版本的lru_cache，仅仅是一个fallback版本罢了这种即使是fallback，也尽全力优化的精神。是现在很多软件开发者们都不具备的。手机内存越来越高，而很多软件却仗着手机硬件优化就忽视了软件优化，但这种现象也只能接受，毕竟性能优化从来不是一件简单的事情。cache_info() 和 cache_clear()函数，其实本可以不需要。他们存在的作用，是为了用户不需要通过复杂的操作，才能读取到缓存的信息update_wrapper函数，专门写来保留用户函数元数据，缩减用户调试时的步骤。代码既是给机器运行的，也是给人读的。好了，中考完后写的第一篇纯技术类型的文章。写的好累，几个月没碰代码，编程能力下降了好多……但最后质量应该还是可以的。下篇再见！
10个月宝宝每天需要喝多少奶粉？
