-
Notifications
You must be signed in to change notification settings - Fork 12.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
cacheMap property optimization #4344
Comments
Because this is not an operation, concurrenthashmap can only guarantee its own operation, and there is a reference replacement operation here |
What should replace the reference? |
What's the meaning of using a set method to replace a reference after synchronized so why not use CAS? |
Maybe what I said is not clear enough. In many cases, not only do operations on the cachemap, it is a complete operation unit, and then why not use concurrent operations, because essentially the contents of the concurrenthashmap are also synchronized for locking |
I think this code can be modified in the following way:
like:
|
Your writing code looks good, but unfortunately now the client only supports the 1.6 jdk version |
|
But in version 2.0 we will upgrade to version 1.8 using java |
|
Welcome to contribute your code |
In JDK1.6,
|
It's looks good,u can try it and test it performance in Nacos |
I wonder why
cacheMap
properties use the AtomicReference wrapper inClientWorker
, but cacheMap writes with lock. What's the point of using AtomicReference? I thinkConcurrentHashMap
could be used to replace it with a lock-free operation to improve concurrency.The text was updated successfully, but these errors were encountered: