[ReentrantLock+普通hashmap】在读多写少的情况下代替ConcurrentHashMap

1)读写锁而不能用chm的例子(读多，且要保证一个业务操作的原子性)

现在突然明白了这2个的场景，因为chm其实只保证对单个操作的原子性，同时保证了并发安全，

但如果一个业务由几个操作组成，那么就不是原子的了。

因此如果涉及到多个线程操作同一个资源，如：网络连接的管理，那么使用chm是不合适的，如果同一个uid的玩家发起多次连接，由于在netty中是连接到不同的worker线程的。

很可能在临界状态下，如果客户端发起多次网络连接，很可能互踢出问题。

这时，就可以用读写锁代替chm。

2)用chm的例子(写多)

由于普通的hashmap不可以在多个线程中同时出现读写，不然就会异常，如果对同一个对象的hash始终在同一个线程中，那么对这个对象的 添加，删除操作就可以在chm中进行，比如：统计一个handler的执行时间，超时了就打印出来这么一个需求。

=========================

总结：

经过大佬的指导，明白了，第一种情况，本质上是线程不安全的问题。 线程不安全指的是：由于多个线程共同修改影响了最后数据的一致性，比如：5个线程做+1操作，但是最后不是5，虽然不报错，其实已经是出错了，出错不一定是抛出异常，结果达不到预期，也是不安全的表现。

session的移除，其实应该是：登录成功后才添加到chm中，而不是一连上socket就添加到chm中。

由于登录后已经有了uid，那么添加和移除，其实可以到玩家线程中搞定，这样子就不会有问题了。

===================20220725===============

如：排行榜，的一个xxxManager,有可能多线程访问到，此时用这个是可以的。 出现死锁的情况必然是：你中有我，我中有你。xxxManager的这种用法，是不会有这种问题的。