协程不阻塞，但反射调用会拖慢调度：Python中getattr/setattr引发同步开销，Java中Method.invoke导致线程池争用，动态import触发模块锁；应预编译访问逻辑、缓存MethodHandle、启动时预加载模块。
协程本身不阻塞，但反射调用会——尤其在高频实例化或动态方法分发场景下，getattr、setattr、method.invoke() 这类操作会显著拖慢事件循环调度节奏。问题不在协程语法，而在反射与异步执行模型的天然冲突。
asyncio 中频繁 getattr/setattr 导致调度延迟
当协程在每次请求中都通过 getattr(obj, field_name) 动态读取字段，或用 setattr(obj, key, value) 填充数据时，Python 解释器需实时查找属性链、触发描述符、校验访问权限——这些全是同步开销。若单次反射耗时超过 10ms，事件循环就无法及时切换其他协程，吞吐量断崖下跌。
- 典型场景：ORM 模型动态赋值、API 请求体自动绑定、验证框架的字段遍历
- 实测对比：静态属性访问（
obj.name）比getattr(obj, 'name')快 3–5 倍；带描述符的setattr可能慢 10 倍以上 - 规避方式：预编译字段访问逻辑，把反射挪到类定义期而非运行时
- 示例：用
__slots__+ 闭包生成固定字段的__init__，避免每次实例化都走字典查找和setattr调度
Java Method.invoke() 在协程式框架中引发线程池争用
虽然 Java 没有原生协程，但在 Vert.x、Project Loom 或基于 Netty 的异步服务中，若业务层大量使用 Method.invoke() 分发请求（比如注解驱动的控制器），每次反射调用都会触发 JNI 进入本地方法，短暂脱离虚拟线程/事件循环上下文，造成调度抖动和线程池任务堆积。
- 关键限制：JVM 对反射调用有内联抑制，HotSpot 不会优化
invoke()调用链，即使方法体极短 - 更优替代：
MethodHandle（Java 7+）或VarHandle（Java 9+），它们可被 JIT 编译为直接调用指令 - 注意点：提前缓存
MethodHandle实例，避免每次请求都调用lookup.findVirtual()——后者本身含反射开销 - 示例：
handle.invokeExact(obj, arg)比method.invoke(obj, arg)平均快 2–4 倍，且无访问检查开销
Python 协程里混用 importlib.import_module 触发模块锁
在异步 Web 路由或插件加载逻辑中，若每个请求都动态调用 importlib.import_module('module.path')，会竞争 CPython 的全局导入锁（import lock）。这个锁是同步的，一旦被一个协程持有，其他所有协程都得排队等待，彻底破坏并发性。
- 常见误用：按请求路径动态导入处理器模块、热重载配置触发反复 import
- 根本解法：启动时预加载全部可能用到的模块，运行时只做字典查表（
handlers[route]） - 折中方案：用
loop.run_in_executor(None, importlib.import_module, name)把 import 移出事件循环，但代价是线程切换开销 - 验证技巧：用
asyncio.current_task().get_coro()配合日志，确认 import 是否出现在 await 链中
反射不是不能用，而是不能“在协程热路径上反复用”。真正卡住性能的，从来不是 async 关键字，而是那些你以为“只是查个属性”的同步操作——它们像细沙一样堵住事件循环的管道口。
