Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The round robin connection strategy will fail in a concurrent environment, because the
Random.Next
is not thread safe.Random
will always return0
when the internal status is broken.For .NET 6+,
Random.Shared
is imported and it can be used in multi-threads scenarios.For .NET Standard 2.1, we have different workarounds to discuss.
1、Just use a new instance each time. The problem is that, if in a very short meanwhile, the results of all randoms are all the same because the seeds are all based on the same timestamp. Also, it allocates more heap memory.
2、Use a single instance with
lock
. It seems to be unacceptable as it'll makeGetConnection
much slower.3、Use
ThreadLocal<Random>
:And in
Dispose
:private void Dispose(bool disposing) { if (isDisposed) return; if (disposing) { // free managed resources foreach (var connection in connections) connection.Dispose(); + localRand.Dispose(); } isDisposed = true; }
The cost is more memory usage as we keep a
Random
instance for every thread visitor.