Java中对于并发问题的处理方法是什么

本篇内容介绍了“Java中对于并发问题的处理免费云主机域名方法是什么”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！首先我们一起回顾一些并发的场景最基本的，我们要弄清楚什么的并发嘞？我简单粗暴的理解就是：一段代码，在同一时间段内，被多个线程同时处理的情况就是并发现象。下面简单画了个图：那么只要是并发现象就需要我们进行并发处理吗？那肯定不是滴。我们就拿大家都能理解的订单业务来举例，比如说下面两种简单的场景：对于C端业务来讲，基本上是由一串随机的序列号组成，可以为UUID、数字串、年月日商户(加密)+随机唯一序列号等等方式。这样的目的也是为了保障商户订单量的安全，防止他人去进行恶意分析。对于B端业务来讲，基本上都是由商户+年月日+顺序递增序列号的方式组成。这样方便客户方进行订单的汇总以及后期的追溯业务。以上两种场景的区别基本上就是随机唯一序列号和顺序递增序列号的区别。伪代码如下：那么对于C端的随机唯一序列号来讲，我认为肯定是没必要进行并发控制的，只要写一个生成随机唯一序列号的算法就好了，这样生成出来的订单号必然是唯一的。但对于B端的顺序递增序列号来讲，就需要进行并发控制了。因为既然要保证顺序递增，我在生成当前序列号的同时就必然需要之前上一个单子的序列号是什么，因此我就必然需要一个地方去存储这个序列号。伪代码如下：此时如果事务为可重复读，Thread1开启事务并获取并修改序列号，此时在Thread1未提交事务之前Thread2开启事务并获取序列号。此时两个线程获取到的序列号必然是一致的，这样就会出现订单号重复的问题。如果更换隔离级别呢？是否能够解决这个问题？读已提交？同样如果在Thread1提交事务之前Thread2就执行完第一步获取最大序列号呢？一样有问题。读未提交？一样的呀，在两个Thread都执行完第一步，但没有执行update的情况。串行化？那就和加同步锁没啥区别的，而且是阻塞式的。一堆请求占用数据库连接阻塞在这里，如果出现资源耗尽的情况就比较严重了。不用事务？这个如果遇到2中的场景也一样的。那么加锁呢？单机环境下我们可以选择Synchronized或Lock来进行处理。众所周知，JDK1.6之后就对Synchronized进行了改进，不再是单纯的阻塞，而是先进行自旋处理，在一定程度上也达到了自旋节省资源的效果。但是Synchronized或Lock还是要根据实际情况来进行处理的。如果我们为了省事而使用Synchronized对事务代码进行加锁的话，首先我们要保证避免长事务的出现，否则响应超时了，而事务还没有释放，那就比较严重了，异常情况堪比锁表。分布式环境下我们可以依赖Redis或Zookeeper来实现分布式锁。这里需要注意的是，如果要依赖Redis实现的话，尽可能保证Redis采用单实例或分片集群的方式进行部署。主从的部署方式在某种极端情况下出现节点宕机时会导致误判的情况。毕竟Redis是AP性质的。还可以通过数据库来实现，比如通过select for update来实现行锁、通过version字段实现乐观锁、添加唯一约束的方式。首先select for update实现行锁和上面的串行化事务差别不大，都是数据库连接的阻塞，不建议使用。而乐观锁和唯一约束的方案更适用于作为一个保底方案，否则人家并发请求的时候只有一个请求能成功，其他的都失败。这样的用户体验也不好。最后我们能得出一个结论。是否进行并发控制要依据该并发操作是否会造成数据安全问题来决定的。好了，下面向大家分享一些在学习工作中对于并发问题的处理思路由于请求重试导致的并发安全问题在与第三方系统交互或者微服务内部跨模块交互时，我们通常会采用HTTP或RPC等方式，并设置最大请求时间以及重试次数。因为我们绝对不允许因为下游服务的异常问题而拖累当前服务的正常运行。而通常情况下，最大请求时间也是根据两个服务之间的实际业务以及下游接口进行多次测试而设定的，一般来说不会随便的出现请求超时的情况。但是一旦下游业务的接口因为某种原因(比如网络卡顿或者出现效率问题)导致请求超时的情况，就很有可能因为上游服务的重试而导致下游服务数据重复的问题。这种情况从本质上来说也就是个重复消费的问题。我们只需要双方配合做好幂等就好了。1.首先，如果涉及到前端，比如说点击前端的按钮触发业务并且调用下游服务的业务。这个时候既要考虑前端重复提交也要考虑后端的重复发送以及重复消费问题。前端最常用的方式就是做一个进度条或进行防抖处理，避免一个用户频繁点击按钮。那么如果是多个用户同时提交同一条数据呢？这个情况主要是在B端业务中出现，比如说多个用户均具有这条数据的修改权限，此时也并发点击按钮提交了这条数据。一般来说，这种情况出现的概率还是极少数的，也不会有多少并发量。因此我们直接采用数据库的乐观锁进行保底控制就好了，只允许一个人操作成功，其他人操作失败并提示该数据已被修改。2.上游服务请求下游服务时，在请求头或消息中添加消息唯一ID。下游服务第一次接收到这个消息后首先将消息保存在缓存中并根据测试结果设置合理的有效期(有效期尽可能比正常请求时间长个一两分钟就好)。这样就可以拦截上述所说的重试导致的重复消费问题。在这里是否有小伙伴会有这样的一个疑问，如果重复发送的消息中messageId不一致或者上游服务接口本身就被调用了多次怎么办？（1）首先，我觉得在上游服务接口本身就被调用了多次的情况下，第一点中的第2步骤(判断数据状态)这种方式就可以把它拦截掉。（2）其次，如果出现重复发送的消息中messageId不一致的情况，我认为这就属于程序员问题了，可以不放在这里进行考虑。如果硬要考虑的话，貌似也没什么更好的办法，那就加锁吧。顺序递增订单号问题在开头我们通过引用这个生成订单号的例子分析了一些什么情况下需要进行并发处理问题，并且上面是采用加锁方式处理的。那么是否还有其他的方式比加锁更好一些呢？比较加锁影响吞吐量呀，哈哈。非必要情况下，我是不会进行加锁处理的，除非在定制开发的过程中，用户的要求是能用就行，那就可以偷懒了哈哈，节省时间去摸鱼！！！！下面给大家分享一些我常用的一种方式：Redis+Lua。我们都知道操作内存肯定是比操作数据库要更快一些的，那么我们可以干脆将各个单据的序列号添加到Redis中。并且订单号是根据年月日来进行重置的，所以我们可以将序列号的过期时间设置为24小时。伪代码如下：我们都清楚，Redis多指令执行是没办法保证原子性的。所以我们要借助Lua脚本将多个Redis执行以脚本的方式执行来保证多指令执行的原子性，再配合Redis基于内存以及单线程执行指令的优势，可以代替锁来赋予功能更大的吞吐量。计数统计问题在工作中我还做过这样一个需求。首先通过消息队列接收、主动拉取数据源的方式获取用户在实际业务中产生的源数据并根据设置的规则比对校验生成符合条件的数据保存在数据库中。并且对通过各个维度对生成的数据进行计数统计并推送下游单据。比如说其中有一个统计维度为“在各个班的工作时间内，根据次数统计符合条件的数据并汇总推送下游单据”。那么要做这项业务，首先我们要对各个班的数据进行分别计数，当前班开始工作时同步开启计数，结束工作时停止计数，当计数器达到设置的标准后，将这些数据进行统计处理后推送下游单据。根据上面的业务，通常来说有两种方式解决：将班、计数量、数据ID等数据存储在数据库中，并对获取数据、处理数据、计数、推送下游单据等操作统一加锁进行处理，保证数据计数的准确性。依然是通过Redis+Lua的方式进行处理。最后通过实际的业务分析决定采用Redis+Lua的方式进行处理。只不过这次的Lua要写相对复杂的业务了。伪代码如下：以上代码是根据我实际的业务代码改编成的伪代码，这个段代码没必要看懂哈，首先是伪代码，其实这个业务比较复杂，我也没写注释。更多的还是分享一下优化的处理思路：首先计数量是由客户定的，可以设置的很小也可以设置的很大。由于这一点考虑，我将计数分成的两部分，一个是String类型的key做计数器，一个是List类型的key用来记录正在被计数的数据ID。这个List有可能是一个大key。所以我们不会去频繁的读取它的数量进行判断，而是通过读取这个String类型的计数器来校验计数。当计数符合条件后就将List取出来。这样做的好处是节省了频繁读取大key的耗时(实际上Redis读取大Key是非常耗时的，我们在实际开发中要时刻注意这一点)。“Java中对于并发问题的处理方法是什么”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注百云主机网站，小编将为大家输出更多高质量的实用文章！

相关推荐: SpringBoot+kaptcha怎么实现验证码

本篇内容主要讲解“SpringBoot+kaptcha怎么实现验证码”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“SpringBoot+kaptcha怎么实现验证码”吧!kaptcha 是一个非常老牌的验证码生成工…