feat: use ConcurrentMap to replace map and mutex

[RealBar]

Compared to map + sync.Mutex, ConcurrentMap is proved reliable and more efficient

[xtaci]

how is this compared with sync.Map?

[codecov[bot]]

Codecov Report

Merging #187 into master will decrease coverage by 1.38%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #187      +/-   ##
==========================================
- Coverage   81.89%   80.51%   -1.39%     
==========================================
  Files          11       11              
  Lines        2055     1863     -192     
==========================================
- Hits         1683     1500     -183     
+ Misses        288      280       -8     
+ Partials       84       83       -1     

Impacted Files	Coverage Δ
sess.go	81.71% <100.00%> (-1.16%)	:arrow_down:
tx.go	70.00% <0.00%> (-5.00%)	:arrow_down:
readloop_linux.go	65.38% <0.00%> (-4.62%)	:arrow_down:
readloop.go	70.83% <0.00%> (-4.17%)	:arrow_down:
tx_linux.go	75.00% <0.00%> (-3.27%)	:arrow_down:
crypt.go	75.74% <0.00%> (-1.54%)	:arrow_down:
timedsched.go	89.70% <0.00%> (-1.44%)	:arrow_down:
fec.go	88.02% <0.00%> (-1.35%)	:arrow_down:
kcp.go	77.61% <0.00%> (-1.19%)	:arrow_down:
... and 2 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update f45217e...0b6888f. Read the comment docs.

[xtaci]

if there's only one link, the benefit from your algorithm is only the xxhash algorithm right? the locking part is still the RLock?

How about caching + sync.Map?

[xtaci]

https://github.com/xtaci/kcp-go/commit/608bd97d7ba75e913e7a11c09c771add11c6d7d5

[RealBar]

segment lock also helps a lot

[RealBar]

benchmark is

BenchmarkConcurrentMap_Write-8 4402040 344 ns/op BenchmarkSyncMap_Write-8 1000000 1869 ns/op BenchmarkConcurrentMap_ReadWrite-8 398430 2947 ns/op BenchmarkSyncMap_ReadWrite-8 365456 3240 ns/op BenchmarkMapMutex_ReadWrite-8 336242 3683 ns/op

[xtaci]

For random r/w, segment lock is efficient surely.

But in kcp-go, for most of the time, just read lock is required to retrieve the session object.

Write lock only happens twice(1. connection establishment, 2. connection termination)