一个奇怪的问题。因为没有明显的性能指标，所以我在这里有不同的想法。我描述这个问题的细节。我正在用dubbo（版本2.6.6）框架开发一个rpc服务，并进行性能测试。有人能帮忙吗？
CPU:8vcores
内存：16g（总计）-xms5g-xmx5g
试验结果：

users     TPS    average-response-time  cpu                  memory     disk-io         
2000      2208          894ms           30%(single-avg)        42%      824    
1000      2071        476ms             30%(single-avg)        42%      849      
500       1863        250               27%(single-avg)        42%      410          
200       1734        105               26%(single-avg)        42%      340

切换上下文数据：
2000个用户

1000个用户

500个用户

200个用户

从这些数据来看，cpu内存、磁盘io和cpu上下文切换，这些指标都是可以的，但是随着用户的增加，tps没有显著增加，但是平均响应时间显著增加。
那么问题出在哪里呢，我知道一些关于锁的东西，或者关于锁的队列，如何测试锁的队列大小？有什么工具可以做这个吗？为什么平均响应时间花费这么多时间？
来自dubbo framework com.alibaba.dubbo.remoting.exchange.support.defaultfuture的密钥代码

@Override
    public Object get() throws RemotingException {
        return get(timeout);
    }

    # THIS METHOD COST MUCH TIME!!!!
    @Override
    public Object get(int timeout) throws RemotingException {
        if (timeout <= 0) {
            timeout = Constants.DEFAULT_TIMEOUT;
        }
        if (!isDone()) {
            long start = System.currentTimeMillis();
            lock.lock();
            try {
                while (!isDone()) {
                    done.await(timeout, TimeUnit.MILLISECONDS);
                    if (isDone() || System.currentTimeMillis() - start > timeout) {
                        break;
                    }
                }
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            } finally {
                lock.unlock();
            }
            if (!isDone()) {
                throw new TimeoutException(sent > 0, channel, getTimeoutMessage(false));
            }
        }
        return returnFromResponse();
    }