【Java并发编程】java高并发的解决方案（一）

旧城等待， 2022-06-06 10:40 264阅读 0赞

对于我们开发的网站，如果网站的访问量非常大的话，我们就需要考虑相关的并发访问问题了。而且并发问题也是中高级工程师面试中必问的问题，今天我们就来系统学习一下。

为了更好的理解并发和同步，我们先学习两个重要的概念：同步和异步。

**1、同步和异步的区别和联系**

所谓同步，可以理解为在执行完一个函数或方法之后，一直等待系统返回值或消息，这时程序是处于阻塞状态的，只有接受到返回值或消息之后才往下执行其他的命令。

所谓异步，执行外函数或方法之后，不必阻塞性地等待返回值或消息，只需要向系统委托一个异步过程，那么当系统接收到返回值或消息时，系统会自动触发委托的异步过程，从而完成一个完整的流程。

**同步在一定程度上可以看作是单线程，这个线程请求一个方法之后就等待这个方法给他回复，否则就不往下执行**。

**异步在一定程度上可以看作多线程，请求一个方法之后就不管了，继续执行其他的方法**。

同步就是一件事，一件事一件事的做。

异步就是，做一件事，不影响做其他的事情。

对于java程序而言，我们会经常听到同步关键字**synchronized**，假如这个同步的监事对象是类，那么当一个对象访问这个类里面的同步方法的时候，其他的对象也想访问这个同步方法就会进入阻塞状态，只有等前一个对象执行完该同步方法，当前对象才能继续执行该方法，这就是同步。相反，如果方法前没有同步关键字修饰的话，那么不同的对象就可以在同一时间访问同一个方法，这就是异步。再补充一下脏数据和不可重复读的概念。

**2、脏数据和不可重复读**

**脏数据：**  
脏读就是指，当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务访问并使用了这个数据。因为这个数据还没有提交，那么另外一个事务读到的数据就是脏数据（dirty data），依据脏数据所做的操作可能是不正确的。

**不可重复读：**  
指在数据库访问中，**一个事务范围内两个相同的查询却返回了不同的数据**。这是由于查询时系统中其它事务修改的提交引起的。一种更容易理解的说法是：在一个事务内，多次读取同一数据。在这个事务还没结束时，另一个事务也访问该数据。那么，在第一个事务的两次读数据之间，由于第二个事务的修改，导致第一个事务两次读到的数据可能不同，因此成为不可重复读，即原始读取不可重复。

**3、如何处理并发和同步**

今天学习的处理并发和同步问题主要是通过**锁机制**。

**锁机制有两个层面：**  
一种是**代码层面**上的，如**java中的同步锁**，典型的就是同步关键字**synchronized和lock**。  
[http://www.cnblogs.com/xiohao/p/4151408.html][http_www.cnblogs.com_xiohao_p_4151408.html]  
[http://www.cnblogs.com/xiohao/p/4151924.html][http_www.cnblogs.com_xiohao_p_4151924.html]  
[http://blog.csdn.net/lmb55/article/details/46279155][http_blog.csdn.net_lmb55_article_details_46279155]

另一种是**数据库层面**上的，比较典型的就是**悲观锁和乐观锁**。  
有关悲观锁和乐观锁的内容请参看：[http://blog.csdn.net/lmb55/article/details/78266667][http_blog.csdn.net_lmb55_article_details_78266667]

**4、常见java并发同步案例分析**

> 案例一：订票系统案例，某航班只有一张机票，假定有1W个人打开你的网站来订票，问你如何解决并发问题（可扩展到任何高并发网站要考虑的并发读写问题）
> 
> 问题，1W个人来访问，要求票没出去前必须保证大家都能看到票，不可能一个人在看到票的时候别人就不能看到。但是最后到底谁能抢到，那得要看这个人的“运气”了（网络快慢等）

首先我们容易想到和并发相关的几个方案：

锁同步更多指的是应用程序的层面，多个线程进来，只能一个一个的访问。除了Java中的对象锁，还有另外一个层面—**数据库锁**。如果是分布式系统，显然只能使用数据库端的锁来实现。

假定我们采用了同步机制或者数据库物理锁机制，如果保证1W个人还能同时看到有票，这显然会牺牲性能，在高并发网站中是不可取的。

由此来看，采用乐观锁即可解决此问题。**乐观锁是在不锁表的情况下，利用业务的控制来解决并发问题，这样既保证数据的并发可读性又保证数据的排他性，保证性能的同时也解决了并发带来的脏数据问题**。

**hibernate如何实现乐观锁：**

**前提**：在现有表中增加一个冗余字段，long类型的version版本号。

**原理：**  
1）只有当前版本号>=数据库表的版本号才能提交  
2）提价成功后，版本号version++

实现很简单：在orgmapping增加一个属性optimistic-lock=”version”即可，以下是样例片段：

<hibernate-mapping>
    <class name="com.stock.ABC" optimistic-lock="version" table="T_Stock" schema="STOCK">
    </hibernate-mapping>

> 案例二：股票交易系统、银行系统，大数据量你是如何考虑的

首先，股票交易系统的行情表，每几秒钟就有一个行情记录产生，一天下来就有（假定行情3s一个）股票数量\*20\*60\*6条记录，一个月下来这个表的记录数量多大？Oracle中一张表的记录数超过100W之后查询性能就很差了，如何保证系统性能？

再比如，中国移动有上亿的用户量，表如何设计？把所有数据存到一张表？

所以，大数据量的系统，必须考虑**表拆分**（表名不一样，但是结构完全一样），通常用到的有以下几种方式（视情况而定）：

> 1）按业务分。比如手机号的表，我们可以考虑130开头的一个表，131开头的另一个表，以此类推。
> 
> 2）利用Oracle的表拆分机制做分表
> 
> 3）如果是交易系统，我们可以考虑按时间轴拆分，当日数据一个表，历史数据弄到其它表。这里历史数据的报表和查询不会影响当日交易。

当然，表拆分后我们的应用要做相应的适配。单纯的orgmapping就得改动了。比如部分业务要通过存储过程等。

此外，我们还要考虑**缓存**：

这里的缓存，指的不仅是hibernate，hibernate本身提供了一级二级缓存。这里的缓存独立于应用，依然是内存的读取。假如我们能减少数据库频繁的访问，那对系统肯定大大有利。比如一个电子商务系统的商品搜索，如果某个关键字的商品经常被搜，那就可以考虑把这部分商品列表存放到缓存（内存）中去，这样不用每次访问数据库，性能大大增加。

简单的缓存我们可以理解为自己做一个HashMap，把经常访问的数据做一个key，value是第一次从数据库搜索出来的值，下次访问就可以从map中读取，而不需要读数据库。目前专业些的有独立缓存框架比如memcached等，可独立部署成一个缓存服务器。

redis实现分布式锁：  
[http://blog.csdn.net/lmb55/article/details/78235768][http_blog.csdn.net_lmb55_article_details_78235768]  
Redis实现秒杀：  
[http://blog.csdn.net/lmb55/article/details/78266905][http_blog.csdn.net_lmb55_article_details_78266905]

**5、常见的提高高并发下访问效率的手段**

**首先要了解高并发的瓶颈在哪里？**

> 1）可能是服务器网络带宽不够  
> 2）可能是web线程连接数不够  
> 3）可能是数据库连接查询上不去

**根据不同的情况，解决思路也不同**

> 1）像第一种情况可以增加网络带宽，DNS域名解析分发多台服务器。  
> 2）负载均衡，前置代理服务器nginx、apache等等。  
> 3）数据库查询优化，读写分离，分表等等。

**最后复制一些在高并发下面常常需要处理的内容：**

> 1）尽量使用缓存，包括用户缓存、信息缓存等，多花点内存来做缓存。可以大量减少与数据库的交互，提高性能。  
> 2）用jprofiler等工具找出性能瓶颈，减少额外开销。  
> 3）优化数据库查询语句，减少直接使用hibernate等工具的直接生成语句（仅耗时较长的查询做优化）  
> 4）优化数据库结构，多做索引，提高查询效率  
> 5）统计的功能尽量做缓存，或按每天统计或者定时统计相关报表，避免需要时进行统计的功能。  
> 6）能使用静态页面的地方尽量使用静态页面，减少容器的解析（尽量将动态内容内容生成静态html显示）。  
> 7）解决以上问题后，使用服务器集群来解决单台的瓶颈问题。

[http_www.cnblogs.com_xiohao_p_4151408.html]: http://www.cnblogs.com/xiohao/p/4151408.html
[http_www.cnblogs.com_xiohao_p_4151924.html]: http://www.cnblogs.com/xiohao/p/4151924.html
[http_blog.csdn.net_lmb55_article_details_46279155]: http://blog.csdn.net/lmb55/article/details/46279155
[http_blog.csdn.net_lmb55_article_details_78266667]: http://blog.csdn.net/lmb55/article/details/78266667
[http_blog.csdn.net_lmb55_article_details_78235768]: http://blog.csdn.net/lmb55/article/details/78235768
[http_blog.csdn.net_lmb55_article_details_78266905]: http://blog.csdn.net/lmb55/article/details/78266905