Sync BitList for all the operations

[AlbumenJ]

What is the purpose of the change

Brief changelog

Verifying this change

Checklist

• 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.
• 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.
• Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
• 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.
• Add some description to dubbo-website project if you are requesting to add a feature.
• GitHub Actions works fine on your own branch.
• If this contribution is large, please follow the Software Donation Guide.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[CrazyHZM]

Read behavior doesn't need to lock.

[He-Pin]

Better to use a read and write lock?

[oxsean]

In general, reading without locking may lead to consistency issues.
@He-Pin If the operation itself is very short, using a read-write lock won't increase throughput. In fact, due to the internal complexity of the lock, it might even slow down. I've tested this with examples before.

[He-Pin]

Great, at least at this case, this is not needed:)

[chickenlj]

LGTM.

Be aware of the potential performance drop caused by lock.