[BUG] Questions about Dubbo Adaptive Load Balance

### Pre-check

- [x] I am sure that all the content I provide is in English.

### Search before asking

- [x] I had searched in the [issues](https://github.com/apache/dubbo/issues?q=is%3Aissue) and found no similar feature requirement.

### Apache Dubbo Component

Java SDK (apache/dubbo)

### Descriptions

Subject: Very Confused About org.apache.dubbo.rpc.AdaptiveMetrics#getLoad, Delay Penalty, and Decay Design
主题：非常疑惑org.apache.dubbo.rpc.AdaptiveMetrics#getLoad，延迟惩罚和衰减的设计

Question:
1. As long as the server responds normally, the currentProviderTime and currentTime will be updated to serviceTime. Then there will be a call to trigger getLoad. As long as there is no clock back, the branch ```if (metrics. currentProviderTime==metrics. currentTime)``` will be reached. Then it will be satisfied. The lastLatency will be set to timeout * 2L. Is this branch a maximum probability? So the actual RT will be overwritten, so is the design here reasonable?
2. As long as getLoad is called once, metrics. ```CurrentProvider Time==metrics. CurrentTime``` will not be satisfied, so what is the design purpose of this branch?
3. ```metrics. lastLatency = metrics. lastLatency >> multiple;``` Does the decay rate occur too quickly?

中文：
1.只要服务端正常响应时，那么currentProviderTime和currentTime就被更新成serviceTime，那么紧接着有一次调用，触发getLoad，只要不发生时钟倒退一定会走到if (metrics.currentProviderTime == metrics.currentTime) 这个分支，那么也一定会满足，就会将lastLatency 置为 timeout * 2L，这个分支是极大概率的吧？那么实际的rt就会被覆盖掉，所以这里设计的是合理吗？
2. 只要调用一次getLoad，那么metrics.currentProviderTime == metrics.currentTime就不会满足，所以这个分支的设计目的是什么？
3.metrics.lastLatency = metrics.lastLatency >> multiple衰减程度是否过快

I hope the experts can help clarify my doubts. clasped fist salute

### Related issues

_No response_

### Are you willing to submit a pull request to fix on your own?

- [x] Yes I am willing to submit a pull request on my own!

### Code of Conduct

- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)