-
-
Notifications
You must be signed in to change notification settings - Fork 15.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
recycler has problems recycling objects in a multi-threaded environment #10986
Milestone
Comments
Hmm... I can't see this. Can you make a screenshot ? |
@chrisvest can you have a look ? |
@normanmaurer Yeah, I'll try to spend some time on this. |
chrisvest
added a commit
to chrisvest/netty
that referenced
this issue
Feb 25, 2021
Motivation: It is possible for two separate threads to race on recycling an object. If this happens, the object might be added to a WeakOrderQueue when it shouldn't be. The end result of this is that an object could be acquired multiple times, without a recycle in between. Effectively, it ends up in circulation twice. Modification: We fix this by making the update to the lastRecycledId field of the handle, an atomic state transition. Only the thread that "wins" the race and succeeds in their state transition will be allowed to recycle the object. The others will bail out on their recycling. We use weakCompareAndSet because we only need the atomicity guarantee, and the program order within each thread is sufficient. Also, spurious failures just means we won't recycle that particular object, which is fine. Result: Objects no longer risk circulating twice due to a recycle race. This fixes netty#10986
chrisvest
added a commit
that referenced
this issue
Feb 26, 2021
Motivation: It is possible for two separate threads to race on recycling an object. If this happens, the object might be added to a WeakOrderQueue when it shouldn't be. The end result of this is that an object could be acquired multiple times, without a recycle in between. Effectively, it ends up in circulation twice. Modification: We fix this by making the update to the lastRecycledId field of the handle, an atomic state transition. Only the thread that "wins" the race and succeeds in their state transition will be allowed to recycle the object. The others will bail out on their recycling. We use weakCompareAndSet because we only need the atomicity guarantee, and the program order within each thread is sufficient. Also, spurious failures just means we won't recycle that particular object, which is fine. Result: Objects no longer risk circulating twice due to a recycle race. This fixes #10986
chrisvest
added a commit
that referenced
this issue
Feb 26, 2021
Motivation: It is possible for two separate threads to race on recycling an object. If this happens, the object might be added to a WeakOrderQueue when it shouldn't be. The end result of this is that an object could be acquired multiple times, without a recycle in between. Effectively, it ends up in circulation twice. Modification: We fix this by making the update to the lastRecycledId field of the handle, an atomic state transition. Only the thread that "wins" the race and succeeds in their state transition will be allowed to recycle the object. The others will bail out on their recycling. We use weakCompareAndSet because we only need the atomicity guarantee, and the program order within each thread is sufficient. Also, spurious failures just means we won't recycle that particular object, which is fine. Result: Objects no longer risk circulating twice due to a recycle race. This fixes #10986
raidyue
pushed a commit
to raidyue/netty
that referenced
this issue
Jul 8, 2022
Motivation: It is possible for two separate threads to race on recycling an object. If this happens, the object might be added to a WeakOrderQueue when it shouldn't be. The end result of this is that an object could be acquired multiple times, without a recycle in between. Effectively, it ends up in circulation twice. Modification: We fix this by making the update to the lastRecycledId field of the handle, an atomic state transition. Only the thread that "wins" the race and succeeds in their state transition will be allowed to recycle the object. The others will bail out on their recycling. We use weakCompareAndSet because we only need the atomicity guarantee, and the program order within each thread is sufficient. Also, spurious failures just means we won't recycle that particular object, which is fine. Result: Objects no longer risk circulating twice due to a recycle race. This fixes netty#10986
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected behavior
An object is collected in a multi-threaded environment and only exists in one queue.
Actual behavior
An object is collected in multiple queues in a multithreaded environment.
Steps to reproduce
Breakpoint debugging recycler.get() method, you will find that there are two queues in the stack, holding the same object.
Minimal yet complete reproducer code (or URL to code)
Netty version
4.1.59.Final-SNAPSHOT
JVM version (e.g.
java -version
)1.8
OS version (e.g.
uname -a
)masos
The text was updated successfully, but these errors were encountered: