You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During encode and decode, fury.setCassloader and fury.clearClassloader are called before and after the actual serialization part; threadLocalFury are applied as default, arising following problems:
ThreadLocalFury introduce at least one fury instance for one thread
Now SOFARPC use ThreadLocalFury, will maintain at least one Fury instance for each thread. Which already introduce large amount ofFury instances while the amount of threads getting larger. (And notice that for each fury instance, its own class resolver, which usually become large object in heap, will be created.) Within this scope, ThreadLocalFury might not be that appropriate for the situation.
New Fury instance created after clearClassLoader is called
The clearClassLoader will clear bindingThreadLocal.furyInstance and give birth to instantiating of new Fury instance. This mechanism aggravate the abundance of fury instances in heap and increasing the likelihood of full GC.
Expected behavior
Growth rate of fury instances should be controllable.
Actual behavior
In our case, 20000 tps introduce 4581 fury instances. (For same situation, hessian could bears for 90 k tps)
Steps to reproduce
Simple benchmark on fury-sofarpc call.
Minimal yet complete reproducer code (or GitHub URL to code)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Frequently creating Fury instance lead to FGC
During
encode
anddecode
,fury.setCassloader
andfury.clearClassloader
are called before and after the actual serialization part; threadLocalFury are applied as default, arising following problems:ThreadLocalFury introduce at least one fury instance for one thread
Now SOFARPC use
ThreadLocalFury
, will maintain at least one Fury instance for each thread. Which already introduce large amount ofFury instances
while the amount of threads getting larger. (And notice that for each fury instance, its own class resolver, which usually become large object in heap, will be created.) Within this scope,ThreadLocalFury
might not be that appropriate for the situation.New Fury instance created after
clearClassLoader
is calledThe
clearClassLoader
will clearbindingThreadLocal.furyInstance
and give birth to instantiating of new Fury instance. This mechanism aggravate the abundance of fury instances in heap and increasing the likelihood of full GC.Expected behavior
Growth rate of fury instances should be controllable.
Actual behavior
In our case, 20000 tps introduce 4581 fury instances. (For same situation, hessian could bears for 90 k tps)
Steps to reproduce
Simple benchmark on fury-sofarpc call.
Minimal yet complete reproducer code (or GitHub URL to code)
Environment
java -version
): 8u291, whateveruname -a
): Darwin Kernel Version 20.6.0, whateverThe text was updated successfully, but these errors were encountered: