[Dubbo-5987] Fix lock in DubboProtocol#getSharedClient

[tangcent]

What is the purpose of the change

• Refactor getSharedClient
• fix What is the advantage of this lock? #5987

Brief changelog

• The current lock mode

        locks.putIfAbsent(key, new Object());
        synchronized (locks.get(key)) {
                //do some thing
                //remove lock
                locks.remove(key);
        }

• The situation which there is a problem:
  When thread A finishes executing locks.putIfAbsent(key, new Object()),
  another thread B which holding the lock executes locks.remove(key),
  and then thread A executes synchronized (locks.get(key)).

• Attempt get lock by computeIfAbsent like this:

        synchronized (locks.computeIfAbsent(key, (k) -> new Object())) {
                try{
                        //do some thing
                } finally {
                        //remove lock
                        locks.remove(key);
            }
        }

• The situation which there is a problem:
  1.When thread A finishes executing synchronized (locks.computeIfAbsent(key, (k) -> new Object())) create the lock LockA And synchronized ,
  2.Another thread B synchronized with LockA,
  3.Thread A executes locks.remove(key).
  4.Thread B hold the LockA And synchronized.
  5.Thread C executing synchronized (locks.computeIfAbsent(key, (k) -> new Object())) create the lock LockC And synchronized .
  -It seems difficult to remove a lock without any threads waiting for it exactly.

Verifying this change

Run test cases.

Follow this checklist to help us incorporate your contribution quickly and easily:

• Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
• Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
• Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
• If this contribution is large, please follow the Software Donation Guide.

[AlbumenJ]

@tangcent hi, thanks for your contribution. Please reslove conficts with the latest master branch.

[tangcent]

@AlbumenJ done

[AlbumenJ]

I think this PR is related with #6102 and #6793. In latest version of master branch, there use a lock object existed permanently to avoid concurrency issues. I am wonder if the conection key will change for each request ? If no, shall we still use the same lock object for the same connect key even when the connect key changed this will cause some memory leak. Compare with the little momory leak, reduce lock object initialization and space recycling behavior maybe more significant ? Also, using synchronized for referenceClientMap will reduce the number of concurrent.

@tangcent How do you think?

[tangcent]

• I think that the definition of the ReferenceClientMap means that it makes sense to cache the ReferenceClient.
  So most of the time the ReferenceClient will be found in the cache without triggering a lock operation.
  Does it make sense to keep a locker in memory for rarely triggered operations?

• On the other hand. The most time consuming step is buildReferenceCountExchangeClient.
  So the only operation in synchronized (referenceClientMap) is put the PENDING_OBJECT .
  And then buildReferenceCountExchangeClient after jump out of the loop and release the lock(synchronized).
  It's my view that using synchronized for referenceClientMap here will reduce very few of concurrent.

---

vs #6793: reduce the memory usage
vs #6102: only reduce a few of concurrent