Benchmark test problem

[fangyincheng]

What happened:

There are these problems, when high concurrency and continuous stress testing:

• 'read tcp io timeout' is frequent
• High CPU and memory footprint

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

[AlexStocks]

After search codes, its key problem is as following:

func (p *RpcClientPackageHandler) Read(ss getty.Session, data []byte) (interface{}, int, error) {
    p.client.pendingLock.RLock()
    defer p.client.pendingLock.RUnlock()
    pkg := &DubboPackage{}

    buf := bytes.NewBuffer(data)
    err := pkg.Unmarshal(buf, p.client)
}

func (p *DubboPackage) Unmarshal(buf *bytes.Buffer, opts ...interface{}) error {
    if len(opts) != 0 { // for client
            pendingRsp := client.GetPendingResponse(SequenceType(p.Header.ID))
    }
}

func (c *Client) GetPendingResponse(seq SequenceType) *PendingResponse {
    c.pendingLock.RLock()
    defer c.pendingLock.RUnlock()

    return c.pendingResponses[SequenceType(seq)]
}

The problem is that you can not use RWMutex.Lock again before releasing it by RWMutex.Unlock referring from sync: document that double RLock isn't safe:

If a goroutine has locked RWMutex for reading, it must not expect this,
or any other goroutine to be able to lock RWMutex for reading until the
first read lock is released. In particular, this prohibits recursive read
locking. The restriction is due to fairness properties: to ensure that
the lock eventually becomes available, a blocked Lock call excludes new
readers from acquiring the lock.