未及时释放FutureContext造成频繁GC问题

[xlq20080808]

• I have searched the issues of this repository and believe that this is not a duplicate.

Environment

• Dubbo version: 3.0.12 3.1.8
• Java version: 1.8

Steps to reproduce this issue

1. consumer及provider 通过环境变量，设置参数 future.sync.set=false
2. provider返回的报文较大
3. 3.0.12版本的调用，dubbo协议不会产生频繁GC问题，triple会产生
4. 3.1.8版本调用，dubbo协议及triple协议都会产生频繁GC问题

Pls. provide [GitHub address] to reproduce this issue.

Expected Behavior

Consumer通过dubbo或triple请求，设置了future.sync.set=false 不会在IntenalThreadLocal中保存返回结果，不再产生频繁GC问题

Actual Behavior

统一设置了参数 future.sync.set=false
3.0.12版本:

Dubbo协议调用

及时清除了FutureContext，生效原因

并在之后响应过程中清除了FutureContext

且因参数future.sync.set=false 之后也不再设置FutureContext，从而能够解决频发GC的情况

Tiple协议调用

Tiple未及时清除了FutureContext原因

且没有在接收到响应后清除InternalThreadLocal
虽参数future.sync.set=false，但已经将FutureContext设置进了InternalThreadLocal，会造成频繁GC的情况
3.1.8版本:
Dubbo协议、Triple协议都没有及时清除FutureContext

Dubbo协议调用

Tiple协议调用

Triple未清除原因 同3.0.12

[AlbumenJ]

3.1.8版本:
Dubbo协议、Triple协议都没有及时清除FutureContext

这个 getAndRemote 之后只是为了还原信息，需要看下第一个把环境污染的行为是什么，不然每一次 get 都应该是空的

[xlq20080808]

3.1.8版本:
Dubbo协议、Triple协议都没有及时清除FutureContext

这个 getAndRemote 之后只是为了还原信息，需要看下第一个把环境污染的行为是什么，不然每一次 get 都应该是空的

应该是不同协议分别在这两处第一次将future设置进了InternalThreadlocal
Triple调用
org.apache.dubbo.rpc.protocol.tri.TripleInvoker#invokeUnary

Dubbo调用
org.apache.dubbo.rpc.protocol.dubbo.DubboInvoker#doInvoke

[AlbumenJ]

但是这个在 Runnable 的 finally 里面应该删除了呀

[xlq20080808]

大佬能否辛苦告知下是在哪清除的呀，我跟debug，一直到dubbo调用完成，业务线程返回结果，FutureContext.getContext()还是能够获取到包含返回结果的future

[liufeiyu1002]

在同步调用时。在消费端 FutureContext.getContext() 是作用在业务线程上的。整个消费调用都是用业务线程上执行的。所以 FutureContext.getContext() 不会被清除，除非手动清除掉 或者业务线程下次调用会覆盖掉旧值。 还有就是在每次调用以后 就 执行 FutureContext.getContext().setCompatibleFuture(appResponseFuture) 注释// save for 2.6.x compatibility, for example, TraceFilter in Zipkin uses com.alibaba.xxx.FutureAdapter 写的是 为了适配 2.6.x，现在 到了3.x 了是不可以考虑移除这段代码了？

[liufeiyu1002]

1. dubbo3.0.12中 直接清除的逻辑就不太合适，会把其他值线程其他变量都清理掉,比如服务端返回的 RpcContext 相关的值，如开启了 future 设置，在响应的时候被清除掉是不合理的。future 的清理 和 处理服务端返回的 attch 参数信息一样。 框架没有合适的处理时机。只能在下次使用的时候清理。或者用户手动清理掉。
2. FutureContext.getContext().setCompatibleFuture 这个不是为了 适配2.6.x 相关的么, 这个代码目前存在会导致 future.sync.set 这个不起作用。 npe 是由因为clearAll了导致的

[xlq20080808]

1. dubbo3.0.12中 直接清除的逻辑就不太合适，会把其他值线程其他变量都清理掉,比如服务端返回的 RpcContext 相关的值，如开启了 future 设置，在响应的时候被清除掉是不合理的。future 的清理 和 处理服务端返回的 attch 参数信息一样。 框架没有合适的处理时机。只能在下次使用的时候清理。或者用户手动清理掉。
2. FutureContext.getContext().setCompatibleFuture 这个不是为了 适配2.6.x 相关的么, 这个代码目前存在会导致 future.sync.set 这个不起作用。 npe 是由因为clearAll了导致的

是的，如果dubbo协议及triple协议中的FutureContext.getContext().setCompatibleFuture仅是适配2.6.x 相关，可删除的话，是可以解决该问题的

[liufeiyu1002]

你可以先写个filter之类的fix 一下， 手动把线程变量里的 future 移除掉，如果你不用到它的话。 因为你返回的响应体较大，多个业务线程比较容易造成内存爆涨 导致gc

[ZPerling]

@AlbumenJ 我们也遇到了类似的问题，严重影响性能

[xlq20080808]

@AlbumenJ 我理解将future放入到InternalThreadlocal是为了兼容2.6.x版本trace功能或其他自定义filter设置回调函数。请教下如果我们这确认没有使用自定义回调，通过filter去除threadlocal中的future是否还有其他风险

[AlbumenJ]

@AlbumenJ 我理解将future放入到InternalThreadlocal是为了兼容2.6.x版本trace功能或其他自定义filter设置回调函数。请教下如果我们这确认没有使用自定义回调，通过filter去除threadlocal中的future是否还有其他风险

如果没有使用可以直接删除