[client] fix writeLac memory leak and thread safety issue

[wenbingshen]

Motivation

When I set explicitLacInterval and enable netty memory leak detection, I find that PendingWriteLacOp has a memory leak, as shown below:

Changes

When PendingWriteLacOp completes, execute ReferenceCountUtil.release(toSend) to release toSend.

After applying this PR, netty detecter will no longer detect leaks during local verification.

[horizonzy]

LGTM.

[horizonzy]

Here we may need to check completed, only completed is false, then trigger callback.

The codes should be

        if (receivedResponseSet.isEmpty()){
            ReferenceCountUtil.release(toSend);
            toSend = null;
            if (!completed) {
                completed = true;
                cb.addLacComplete(lastSeenError, lh, ctx);
            }
        }

[wenbingshen]

@horizonzy After reviewing the implementation of PendingWriteLacOp, I found that the implementation of writeLacComplete did not meet the requirements of multi-threaded concurrency safety, so I revised the PR. PTAL.

[lhotari]

just wondering if initiate should also be made synchronized or toSend volatile. Since this method is only called once, it's most likely not necessary if the reference of PendingWriteLacOp is passed across threads using ways where happens-before is ensured (such as passing the reference via an Executor, ConcurrentHashMap or other solutions that already ensure happens-before).

[lhotari]

Is it necessary to execute callbacks outside of the synchronized block? Perhaps not in this case. In general it's a recommended pattern to avoid dead locks by limiting the scope of synchronization when possible so that outgoing calls don't end up causing dead locks by locking other resources. In this case there's probably not other threads that could hold those required locks while it calls this writeLacComplete method and would cause a deadlock.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.