AlexStocks commented on issue #2031: URL: https://github.com/apache/dubbo-go/issues/2031#issuecomment-4275032902
> [@AlexStocks](https://github.com/AlexStocks) https://claude.ai/share/baf1073b-4359-481a-9426-a1eb491f8761 claude 结论很明确： **不要用 sync.Pool，也不要做 MergeURL(serviceURL, referenceURL) 的全局缓存。** 最终认为这两个方向都只是表面优化，或者会引入正确性问题。 最后收敛到的方案是： **把 MergeURL 的执行时机从“每次 RPC 调用”前移到“Invoker 创建时”只做一次。** 也就是在 InvokerDelegate 初始化时预先算好 mergedURL，后续 GetURL() 直接返回这个已经合并好的结果，不再每次调用都 Clone + Merge。 对话里的理由是： providerURL 和 consumerURL 在 invoker 生命周期内基本不变。 现在的问题本质上是 GetURL() 每次 RPC 都触发 common.MergeURL()，而 MergeURL() 内部 Clone() 每次都会分配新对象，造成大量短命对象和 GC 压力。 如果在 invoker 创建时算一次，后面直接复用，就能把热路径上的分配降到 0 allocs/op。 这个方案不需要额外的缓存失效逻辑，因为服务变更时本来就会创建新的 invoker，生命周期天然保证数据新鲜。 对话里明确否掉了两个备选方案： sync.Pool：只能减轻分配压力，不能真正解决 retention；而且还要求调用方正确 ReleaseURL()，改动面大，容易出错。 基于 serviceURL.String() + referenceURL.String() 的缓存：必须在其他路径补 InvalidateMergeURLCache()，否则会返回过期 merged URL；而且 URL.String() 自己也有分配成本。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
