Java高并发如何解决什么方式解决修订稿Word格式.docx
- 文档编号:21001355
- 上传时间:2023-01-26
- 格式:DOCX
- 页数:12
- 大小:222.10KB
Java高并发如何解决什么方式解决修订稿Word格式.docx
《Java高并发如何解决什么方式解决修订稿Word格式.docx》由会员分享,可在线阅读,更多相关《Java高并发如何解决什么方式解决修订稿Word格式.docx(12页珍藏版)》请在冰豆网上搜索。
对于Java程序员而言,我们会经常听到同步关键字synchronized,假如这个同步的监视对象是类的话,那么如果当一个对象
访问类里面的同步方法的话,那么其它的对象如果想要继续访问类里面的这个同步方法的话,就会进入阻塞,只有等前一个对象
执行完该同步方法后当前对象才能够继续执行该方法。
这就是同步。
相反,如果方法前没有同步关键字修饰的话,那么不同的对象
可以在同一时间访问同一个方法,这就是异步。
在补充一下(脏数据和不可重复读的相关概念):
脏数据
脏读就是指当一个事务正在访问数据,并且对数据进行了修改,而这种修改还没有提交到数据库中,这时,另外一个事务也访问这个数据,然后使用了这
个数据。
因为这个数据是还没有提交的数据,那么另外一个事务读到的这个数据是脏数据(DirtyData),依据脏数据所做的操作可能是不正确的。
不可重复读
不可重复读是指在一个事务内,多次读同一数据。
在这个事务还没有结束时,另外一个事务也访问该同一数据。
那么,在第一个事务中的两次读数据之间,由于第二个事务的修改,那么第一个事务两次读到的数据可能是不一样的。
这样就发生了在一个事务内两次读到的数据是不一样的,因此称为是不可重复读
2、如何处理并发和同步
今天讲的如何处理并发和同同步问题主要是通过锁机制。
我们需要明白,锁机制有两个层面。
一种是代码层次上的,如java中的同步锁,典型的就是同步关键字synchronized,这里我不在做过多的讲解,
感兴趣的可以参考:
另外一种是数据库层次上的,比较典型的就是悲观锁和乐观锁。
这里我们重点讲解的就是悲观锁(传统的物理锁)和乐观锁。
悲观锁(PessimisticLocking):
悲观锁,正如其名,它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,
在整个数据处理过程中,将数据处于锁定状态。
悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统
中实现了加锁机制,也无法保证外部系统不会修改数据)。
一个典型的倚赖数据库的悲观锁调用:
select*fromaccountwherename=”Erica”forupdate
这条sql语句锁定了account表中所有符合检索条件(name=”Erica”)的记录。
本次事务提交之前(事务提交时会释放事务过程中的锁),外界无法修改这些记录。
Hibernate的悲观锁,也是基于数据库的锁机制实现。
下面的代码实现了对查询记录的加锁:
StringhqlStr="
fromTUserasuserwhere='
Erica'
"
;
Queryquery=(hqlStr);
("
user"
;
UPGRADE_NOWAIT:
Oracle的特定实现,利用Oracle的for
updatenowait子句实现加锁。
上面这两种锁机制是我们在应用层较为常用的,加锁一般通过以下方法实现:
注意,只有在查询开始之前(也就是Hiberate生成SQL之前)设定加锁,才会
真正通过数据库的锁机制进行加锁处理,否则,数据已经通过不包含forupdate
子句的SelectSQL加载进来,所谓数据库加锁也就无从谈起。
为了更好的理解select...forupdate的锁表的过程,本人将要以mysql为例,进行相应的讲解
1、要测试锁定的状况,可以利用MySQL的CommandMode,开二个视窗来做测试。
表的基本结构如下:
表中内容如下:
开启两个测试窗口,在其中一个窗口执行select*fromtaforupdate0
然后在另外一个窗口执行update操作如下图:
等到一个窗口commit后的图片如下:
到这里,悲观锁机制你应该了解一些了吧~
需要注意的是forupdate要放到mysql的事务中,即begin和commit中,否者不起作用。
至于是锁住整个表还是锁住选中的行,请参考:
至于hibernate中的悲观锁使用起来比较简单,这里就不写demo了~感兴趣的自己查一下就ok了~
乐观锁(OptimisticLocking):
相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制。
悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。
但随之
而来的就是数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。
如一个金融系统,当某个操作员读取用户的数据,并在读出的用户数
据的基础上进行修改时(如更改用户帐户余额),如果采用悲观锁机制,也就意味着整个操作过程中(从操作员读出数据、开始修改直至提交修改结果的全
过程,甚至还包括操作员中途去煮咖啡的时间),数据库记录始终处于加锁状态,可以想见,如果面对几百上千个并发,这样的情况将导致怎样的后果。
乐
观锁机制在一定程度上解决了这个问题。
乐观锁,大多是基于数据版本Version)记录机制实现。
何谓数据版本即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通
过为数据库表增加一个“version”字段来实现。
读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。
此时,将提交数据的版本数据与数据
库表对应记录的当前版本信息进行比对,如果提交的数据?
版本号大于数据库表当前版本号,则予以更新,否则认为是过期数据。
对于上面修改用户帐户信息
的例子而言,假设数据库中帐户信息表中有一个?
version字段,当前值为1;
而当前帐户余额字段(balance)为$100。
操作员A此时将其读出
(version=1),并从其帐户余额中扣除$50($100-$50)。
2在操作员A操作的过程中,操作员B也读入此用户信息(version=1),并从其帐
户余额中扣除$20($100-$20)。
3操作员A完成了修改工作,将数据版本号加一(version=2),连同帐户扣除后余额(balance=$50),提交
至数据库更新,此时由于提交数据版本大于数据库记录当前版本,数据被更新,数据库记录version更新为2。
4操作员B完成了操作,也将版本号加一
(version=2)试图向数据库提交数据(balance=$80),但此时比对数据库记录版本时发现,操作员B提交的数据版本号为2,数据库记录当前版
本也为2,不满足“提交版本必须大于记录当前版本才能执行更新“的乐观锁策略,因此,操作员B的提交被驳回。
这样,就避免了操作员B用基于
version=1的旧数据修改的结果覆盖操作员A的操作结果的可能。
从上面的例子可以看出,乐观锁机制避免了长事务中的数据库加锁开销(操作员A
和操作员B操作过程中,都没有对数据库数据加锁),大大提升了大并发量下的系统整体性能表现。
需要注意的是,乐观锁机制往往基于系统中的数据存储
逻辑,因此也具备一定的局限性,如在上例中,由于乐观锁机制是在我们的系统中实现,来自外部系统的用户余额更新操作不受我们系统的控制,因此可能
会造成脏数据被更新到数据库中。
在系统设计阶段,我们应该充分考虑到这些情况出现的可能性,并进行相应调整(如将乐观锁策略在数据库存储过程中实
现,对外只开放基于此存储过程的数据更新途径,而不是将数据库表直接对外公开)。
Hibernate在其数据访问引擎中内置了乐观锁实现。
如果不用考虑外
部系统对数据库的更新操作,利用Hibernate提供的透明化乐观锁实现,将大大提升我们的生产力。
version="
>
<
!
DOCTYPEhibernate-mappingPUBLIC
"
-
onfigure();
SessionFactorysf=();
Sessionsession=();
Transactiontx=();
xecuteUpdate();
Useruser=(User),1);
221"
);
niqueResult();
Transactiontx=();
101"
();
Transactiontx2=();
(10000);
100"
能web线程连接数不够
3.可能数据库连接查询上不去。
根据不同的情况,解决思路也不同。
1.像第一种情况可以增加网络带宽,DNS域名解析分发多台服务器。
2.负载均衡,前置代理服务器nginx、apache等等
3.数据库查询优化,读写分离,分表等等
最后复制一些在高并发下面需要常常需要处理的内容:
尽量使用缓存,包括用户缓存,信息缓存等,多花点内存来做缓存,可以大量减少与数据库的交互,提高性能。
用jprofiler等工具找出性能瓶颈,减少额外的开销。
优化数据库查询语句,减少直接使用hibernate等工具的直接生成语句(仅耗时较长的查询做优化)。
优化数据库结构,多做索引,提高查询效率。
统计的功能尽量做缓存,或按每天一统计或定时统计相关报表,避免需要时进行统计的功能。
能使用静态页面的地方尽量使用,减少容器的解析(尽量将动态内容生成静态html来显示)。
解决以上问题后,使用服务器集群来解决单台的瓶颈问题。
java高并发,如何解决,什么方式解决
之前我将高并发的解决方法误认为是线程或者是队列可以解决,因为高并发的时候是有很多用户在访问,导致出现系统数据不正确、丢失数据现象,所以想到的是用队列解决,其实队列解决的方式也可以处理,比如我们在竞拍商品、转发评论微博或者是秒杀商品等,同一时间访问量特别大,队列在此起到特别的作用,将所有请求放入队列,以毫秒计时单位,有序的进行,从而不会出现数据丢失系统数据不正确的情况。
今天我经过查资料,高并发的解决方法有俩种:
一种是使用缓存、另一种是使用生成静态页面;
还有就是从最基础的地方优化我们写代码减少不必要的资源浪费:
(
1.不要频繁的new对象,对于在整个应用中只需要存在一个实例的类使用单例模式.对于String的连接操作,使用StringBuffer或者StringBuilder.对于utility类型的类通过静态方法来访问。
2.避免使用错误的方式,如Exception可以控制方法推出,但是Exception要保留stacktrace消耗性能,除非必要不要使用instanceof做条件判断,尽量使用比的条件判断方式.使用JAVA中效率高的类,比如ArrayList比Vector性能好。
)
首先缓存技术我一直没有使用过,我觉得应该是在用户请求时将数据保存在缓存中,下次请求时会检测缓存中是否有数据存在,防止多次请求服务器,导致服务器性能降低,严重导致服务器崩溃,这只是我自己的理解,详细的资料还是需要在网上收集;
使用生成静态页面我想大家应该不模式,我们见过很多网站当在请求的时候页面的后最已经变了,如该页面其实是一个服务器请求地址,在转换成htm后,访问速度将提升,因为静态页面不带有服务器组件;
在这里我就多多介绍一下:
一、什么是页面静态化:
简单的说,我们如果访问一个链接,服务器对应的模块会处理这个请求,转到对应的jsp界面,最后生成我们想要看到的数据。
这其中的缺点是显而易见的:
因为每次请求服务器都会进行处理,如果有太多的高并发请求,那么就会加重应用服务器的压力,弄不好就把服务器搞down掉了。
那么如何去避免呢如果我们把对请求后的结果保存成一个html文件,然后每次用户都去访问,这样应用服务器的压力不就减少了
那么静态页面从哪里来呢总不能让我们每个页面都手动处理吧这里就牵涉到我们要讲解的内容了,静态页面生成方案…我们需要的是自动的生成静态页面,当用户访问,会自动生成,然后显示给用户。
二、下面我们在简单介绍一下要想掌握页面静态化方案应该掌握的知识点:
1、基础-URLRewrite
什么是URLRewrite呢URL重写。
用一个简单的例子来说明问题:
输入网址,但是实际上访问的却是,那我们就可以说URL被重写了。
这项技术应用广泛,有许多开源的工具可以实现这个功能。
2、基础-Servlet
如果你还不知道中一个请求和一个servlet是如何匹配到一起的,那么请搜索一下servlet的文档。
这可不是乱说呀,有很多人就认为/xyz/*.do这样的匹配方式能有效。
如果你还不知道怎么编写一个servlet,那么请搜索一下如何编写servlet.这可不是说笑呀,在各种集成工具漫天飞舞的今天,很多人都不会去从零编写一个servlet了。
三、基本的方案介绍
其中,对于URLRewriter的部分,可以使用收费或者开源的工具来实现,如果url不是特别的复杂,可以考虑在servlet中实现,那么就是下面这个样子:
总结:
其实我们在开发中都很少考虑这种问题,直接都是先将功能实现,当一个程序员在干到1到2年,就会感觉光实现功能不是最主要的,安全性能、质量等等才是一个开发人员最该关心的。
今天我所说的是高并发。
我的解决思路是:
1、采用分布式应用设计
2、分布式缓存数据库
3、代码优化
Java高并发的例子:
具体情况是这样:
通过java和数据库,自己实现序列自动增长。
实现代码大致如下:
id_table表结构,主要字段:
id_namevarchar2(16);
id_valnumber(16,0);
id_prefixvarchar2(4);
extStringValue(idName);
}
}
具体使用者,都是通过类似这种方式:
("
PAY_LOG"
来调用。
问题:
(1)当出现并发时,有时会获取重复的ID;
(2)由于服务器做了相关一些设置,有时调用这个方法,好像还会导致超时。
为了解决问题
(1),考虑过在方法getNextStringValue上,也加上synchronized,同步关键字过多,会不会更导致超时
跪求大侠提供个解决问题的大概思路!
!
解决思路一:
1、推荐?
adyliu/idcenter
2、可以通过第三方redis来实现。
1、出现重复ID,是因为脏读了,并发的时候不加synchronized比如会出现问题
2、但是加了synchronized,性能急剧下降了,本身java就是多线程的,你把它单线程使用,不是明智的选择,同时,如果分布式部署的时候,加了synchronized也无法控制并发
3、调用这个方法,出现超时的情况,说明你的并发已经超过了数据库所能处理的极限,数据库无限等待导致超时
基于上面的分析,建议采用线程池的方案,支付宝的单号就是用的线程池的方案进行的。
数据库update不是一次加1,而是一次加几百甚至上千,然后取到的这1000个序号,放在线程池里慢慢分配即可,能应付任意大的并发,同时保证数据库没任何压力。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Java 并发 如何 解决 什么 方式 修订稿