全部回帖
用户名+锁的一个 map 是为了保证一个用户名在同一时刻只有一个线程在操作的,这做法给搞复杂了但确实有用 😄
用户名+锁的一个 map 是为了保证一个用户名在同一时刻只有一个线程在操作的,这做法给搞复杂了但确实有用 😄
那这样根本不需要用锁,用ConcurrentHashMap就行,用户名作为key,每次putIfAbsent如果返回的是null,那说明还没有线程在进行插入,当前线程进行插入操作。而如果不为null,直接返回就行了
那这样根本不需要用锁,用ConcurrentHashMap就行,用户名作为key,每次putIfAbsent如果返回的是null,那说明还没有线程在进行插入,当前线程进行插入操作。而如果不为null,直接返回就行了
那这样根本不需要用锁,用ConcurrentHashMap就行,用户名作为key,每次putIfAbsent如果返回的是null,那说明还没有线程在进行插入,当前线程进行插入操作。而如果不为null,直接返回就行了
那这样根本不需要用锁,用ConcurrentHashMap就行,用户名作为key,每次putIfAbsent如果返回的是null,那说明还没有线程在进行插入,当前线程进行插入操作。而如果不为null,直接返回就行了
你可以试试,这样好像不行。
你可以试试,这样好像不行。
那这样根本不需要用锁,用ConcurrentHashMap就行,用户名作为key,每次putIfAbsent如果返回的是null,那说明还没有线程在进行插入,当前线程进行插入操作。而如果不为null,直接返回就行了
那这样根本不需要用锁,用ConcurrentHashMap就行,用户名作为key,每次putIfAbsent如果返回的是null,那说明还没有线程在进行插入,当前线程进行插入操作。而如果不为null,直接返回就行了
那这样的话,map是不是会越来越大呢
那这样的话,map是不是会越来越大呢
用户名+锁的一个 map 是为了保证一个用户名在同一时刻只有一个线程在操作的,这做法给搞复杂了但确实有用 😄
用户名+锁的一个 map 是为了保证一个用户名在同一时刻只有一个线程在操作的,这做法给搞复杂了但确实有用 😄
我才看明白。。。最笨的方法吧只能说。。。java提供了那么多线程安全的方式不用,要自己写一个map。。。。
我才看明白。。。最笨的方法吧只能说。。。java提供了那么多线程安全的方式不用,要自己写一个map。。。。
我不推荐用线程锁,不说性能和调优,集群部署以后就没啥用了。换成redis锁吧。然后这种单表单字段的查询肯定要加索引啊。
我不推荐用线程锁,不说性能和调优,集群部署以后就没啥用了。换成redis锁吧。然后这种单表单字段的查询肯定要加索引啊。
这种服务基本上都会部多实例服务吧。反正我们平时不用线程锁,直接怼redis锁或者索引怼库就行了。这种注册业务并发量也不会特别大,一般不会造成数据库连接池爆掉的情况。
这种服务基本上都会部多实例服务吧。反正我们平时不用线程锁,直接怼redis锁或者索引怼库就行了。这种注册业务并发量也不会特别大,一般不会造成数据库连接池爆掉的情况。
我不推荐用线程锁,不说性能和调优,集群部署以后就没啥用了。换成redis锁吧。然后这种单表单字段的查询肯定要加索引啊。
我不推荐用线程锁,不说性能和调优,集群部署以后就没啥用了。换成redis锁吧。然后这种单表单字段的查询肯定要加索引啊。
这种服务基本上都会部多实例服务吧。反正我们平时不用线程锁,直接怼redis锁或者索引怼库就行了。这种注册业务并发量也不会特别大,一般不会造成数据库连接池爆掉的情况。
这种服务基本上都会部多实例服务吧。反正我们平时不用线程锁,直接怼redis锁或者索引怼库就行了。这种注册业务并发量也不会特别大,一般不会造成数据库连接池爆掉的情况。
这个不就和
这个不就和
这不就和超卖问题比较像么,新增用户前要先校验库里的数据。直接保证查询和新增这两步操作的原子性就好啦
这不就和超卖问题比较像么,新增用户前要先校验库里的数据。直接保证查询和新增这两步操作的原子性就好啦
reentrantlock有啥用? 难道你服务就一个节点吗? 超过一个那就跟没有一样
reentrantlock有啥用? 难道你服务就一个节点吗? 超过一个那就跟没有一样
上海匡慧网络科技有限公司 沪B2-20211235 沪ICP备2021021198号-6 Copyright ©2021 KUANGHUI All Rights Reserved. 匡慧公司 版权所有