去年写了两篇分析 decorator 的 blog:
在线上项目里一直也没有用 pypi 的 decorator 库去替换自己的实现，最近替换后撞上了一些问题，整个问题追查过程也各种艰辛，记录一下
我们线上用的 flask 0.11.1 + celery 3.1.25 + gevent 1.2.2 在跑任务队列，broken 用的阿里云 redis 2.8，某个周末突然发现 worker 工作不正常，有大量的 db 连接报错，在简短排查后没找到原因，重启整个服务，暂时跳过这个问题，其实后面还在有其他错误，但也没有解决思路
等周一到公司，团队的人对比了下问题现场和思路，只能发现是 celery worker 会莫名卡死，跑到我们的 k8s 集群上看，对应的 pod 是 running，但是 flower 上看监控是 offline，直接切进 pod 看日志，好几个最后都断在 requests 发请求出去的地方，N 脸懵逼，我们又没升级系统又没动依赖，怎么就会冒出来这个问题
既然最后死在 requests 那，虽然看后面的 Changelog 没发现有跟我们直接习惯的，但还是先把 requests 版本从 2.19.0 升到 2.21.0，并把依赖的库也同步升级。然而并没有解决问题，还是一样的死，还是一样的错
后面多看了几个问题现场，只能协助定位还可能会卡死在 db 读写的地方，这个时候开始怀疑 gevent，因为这货帮忙做了 IO 异步优化，强行协程化，而且这个版本也有点老，期间看也有一些可能相关的 Issue，升级 1.4.0 后发现服务起不来，查了下看需要把 celery 升级到 4.x，但 4.x 的 celery 参数序列化从 pickle 改成 json，还要改挺多代码的，只能先搁置
后面还查了下 celery 的版本问题，我们用的 3.x 是有点老了，但 4.x 那个参数结构该动那个有大所以一直没动，另外也查用 redis 做 broken 的锅，没有任何有效的相关信息
出问题前我在代码里替换了一版 lock 的实现，以及 lock_decorator 的实现，但是往这边怀疑也不对，因为有的出错的地方并没有用到锁，而且看日志和报错也跟锁没有关系
等过了一周，第二个周末的时候开脑洞说好像现在有问题的方法都有修饰器包着，而且这些修饰器都用了 decorator 库，也许这里可能有问题？我们的 decorator 用的是 4.3.0，最新的版本是 4.3.2，大致看了下 Changelog，似乎提到有修复协程问题，但是是 python 3.5 的，不过反正不用改代码，先升了再说
升完后问题真的消失了，那么就来看看到底哪里可能有问题吧。对比期间的变更记录 https://github.com/micheles/decorator/compare/4.3.0…4.3.2，除了一些文档变化和对 py3.5 的协程修复，比较值得怀疑的是 https://github.com/micheles/decorator/commit/eb890d98739196b83f1ecb5cb7bcfe9739a9502c 这个提交，decorator 的原理是在内存里新建一个虚拟文件，把要修饰的方法的相关属性写到这个虚拟文件里，然后通过虚拟文件里的同名方法调装饰器逻辑，装饰器方法里再去调到最终的方法，而这个虚拟文件如果只用 itertools.count()，在 gevent 的协程调度下可能会重名，然后整个代码体系就崩了