请求中生成的单例, 挂载到容器的动态属性上.
持有”进程级容器”, 当绑定不存在时, 到”进程级容器” 上查找之....所谓容器, 相当于一个全局的工厂. 可以在这里 “注册” 各种服务的工厂方法, 再使用容器统一地获取....所以直接使用了 Laravel 的 Application 做 “进程级容器”, 确保自己请求中用到的核心业务逻辑都不注册到 laravel中, 避免污染....就我发现, 最容易导致内存泄露的两种情况:
某个闭包在每次请求时生成一个闭包实例, 被每个容器持有
容器生成的某个服务是匿名类, 导致相互持有
简单来说, 就是定义闭包和匿名类时, 慎重考虑内存泄露的可能性就行...2791,"memory":10485760}
Swoole 除了免去了每次请求启动系统的开销之外, 还带来了额外的性能提升:
由于大量使用 PHP 的反射特性来实现复杂的依赖注入, 所以反射本应该是性能开销的大头