-
Notifications
You must be signed in to change notification settings - Fork 169
[Improvement] No need to use synchronized lock of the method scope when getting client #82
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
Conversation
…en getting client
|
I can't tell the difference, we use the |
|
The lock is just to avoid concurrency conflict on initialization of client. Once Instance is initialized, no need to lock. Right? @jerqi |
I got your point. But I prefer use LazyHolder |
|
Yes. Double-ckeck lock / enum / Inner class are all optional for this requirement. If u prefer inner class. i will update new one later. |
We should unify our style. We use inner class in the other places. |
Codecov Report
@@ Coverage Diff @@
## master #82 +/- ##
============================================
- Coverage 56.39% 56.31% -0.09%
- Complexity 1173 1174 +1
============================================
Files 149 149
Lines 7953 7977 +24
Branches 761 765 +4
============================================
+ Hits 4485 4492 +7
- Misses 3226 3242 +16
- Partials 242 243 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. |
jerqi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
What changes were proposed in this pull request?
[Improvement] No need to use synchronized lock of the method scope when getting client
Why are the changes needed?
Avoid unnecessary lock to improve performance.
Does this PR introduce any user-facing change?
No
How was this patch tested?
No need.