java web中的多线程_java web 开发中的多线程

前言

“常见的javaEE中,例如SSM架构或者SpringBoot项目中我们对多线程和数据重入的感知是很小的,本篇文章将对多线程中的线程之间的协程合作(锁或通信),锁到达了什么粒度,避免数据重入的方式,怎样正确的使用框架解决问题进行阐述”

1. mysql+tomcat多线程(事务模型)解决了的数据重入问题

现在常见的javaEE开发一般是使用 tomcat+(框架)+ mysql 来完成多线程之间数据不重入问题的,tomcat解决了多线程模型,并封装好nio,而mysql作为存储数据的工具,则解决了多线程模型下数据安全的问题.

多线程+数据存储     —–框架—->        tomcat多线程+mysql多事务处理数据

使用这两个框架组合,并合理使用事务和update锁能够使(当这两个组件运行正常时),达到金融级软件的操作,并能够更合理充分的使用服务器资源(合理且小的锁粒度和数据结构)

2. 存储在MySQL中的数据重入问题

我们先要知道mysql默认事务不会出现和会出现的问题

2.1 mysql inodb 默认事务隔离条件

默认情况下mysql 事务的隔离级别是可重复读,在多线程操作下不会出现脏读,第一类丢失更新,第二类丢失更新的问题

但是会出现幻读的问题第一类丢失更新：

在没有事务隔离的情况下，两个事务A B 都对同一 数据S 做修改， A修改S成功后，B修改失败发生回滚，回滚的S导致A的修改被覆盖成原先的数据。导致两次对S的修改都失败。

READ COMMITTED以及以上的隔离机制都能解决。脏读

事务A B处理同一条数据S，在事务A修改了S这条数据但是还未提交数据时，事务B读取了事务A修改后的数据S，然后事务A回滚了，导致事务B读取的该条数据S是不存在的。因为S是之前的内容

REPEATABLE READ隔离机制就能解决不可重复读

还是事务A B处理同一条数据S，事务A读取了数据S，然后事务B修改了数据S，然后事务A又读取了数据S，此时事务A读取的两次S的数据是事务B修改前后的数据，显然不同

REPEATABLE READ隔离机制就能解决第二类丢失不可重复读的特例

事务A B处理同一条数据S，事务A把S修改成了S1，事务B后来又把S修改成了S2，然而事务B修改的S2没有在S1的基础上，导致事务A的修改没有作用了，也就是失败了。幻读

幻读，并不是说两次读取获取的结果集不同，幻读侧重的方面是某一次的 select 操作得到的结果所表征的数据状态无法支撑后续的业务操作。更为具体一些：select 某记录是否存在，不存在，准备插入此记录，但执行 insert 时发现此记录已存在，无法插入，此时就发生了幻读。不同于不可重复读。

2.2 数据重入的避免

由于我们的业务数据并不存储在java内存中,而是通过 mysql driver直接调用mysql,所以多线程问题变成了多事务访问mysql数据的问题,只要解决了mysql多事务下的数据锁的正确使用,就解决了数据的不可预期性变化.

我们的一些简单业务一般设置为普通事务,他们同时也是默认的事务自动提交,如果这些业务不会发生幻读,直接使用即可.

** 另一种不允许幻读出现情况的解决方式: **

3. 存储在JAVA中的数据重入问题

3.1 被重入的是全局变量

当一些全局数据要被多线程操作的时候,就会出现数据重入,导致结果没有向预期结果发生

对于这些数据,优先使用原子类或线程安全的集合类(他们的粒度小,并且使用乐观锁)

3.2 被重入的是一段业务操作

当需要的锁的条件比较复杂时,使用串行锁关键字(注意保证业务情况下粒度尽可能小)或外部数据结构解决(redis+锁 / mysql + 锁)避免数据重入

3.3 java解决数据重入的方式 图解:

4. 思考:多线程/进程解决了什么问题,出现了什么问题?

4.1解决了:更充分使用服务器资源:  包括 磁盘io,网络io,内存,cpu etc

用户体验

听歌+编程+写blog+挣钱 同时进行大量异步结构 :  什么东西不卡这,放后台执行,回调函数来

类似mq,异步servlet, 我不苦等结果返回,而是把要处理的数据放到队列或其它数据结构中,单开出线程或消费者去跑数据,消耗cpufork/join map/reduce 模型的出现

多线程或分布式进程通过通信去合作完成 跑数据操作,大家汇集自己的工作成果然后得到全局的工作成果

4.2 缺点:管理复杂性(数据重入问题)

分布式情况下的cap 问题:强一致性(Consistency)

可用性(Availability)

分区容错性(Partition toleranceCA　　-单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。

注：传统Oracle数据库CP　　-满足一致性、分区容错性的系统，通常性能不是特别高。

注：大多数网站架构的选择AP　　-满足可用性、分区容错性的系统，通常可能对一致性要求低一些。

注：redis、mongodb更高效,更小粒度的框架nio/aio for 异步io

乐观锁

编程过程中不可预期的错误死锁问题

数据重入

框架上手难度高

References