is item.RLock() among table.items‘s traversal in expirationCheck() necessary?

[Deep-Coder-zhui]

because of the existing of table.Lock()，a table items‘s traversal is not concurrent, so I think item.RLock() may be not needed.

[muesli]

I think you may be onto something indeed. It was there to protect the package's user from concurrently changing the CacheItem's properties. But since the only members we access are only mutable by the CacheTable itself, we could probably remove the lock.

[Deep-Coder-zhui]

I get it, thanks @muesli

[vaibhavsanap]

HI @Deep-Coder-zhui / @muesli
Removing the item lock causing the race condition(failure of go test --race). Can we close this issue without doing change.