Java高并发解决方案

最新推荐文章于 2024-07-16 05:20:46 发布

star.29

最新推荐文章于 2024-07-16 05:20:46 发布

阅读量839

点赞数 1

分类专栏： Java 文章标签： Java高并发解决方案

本文链接：https://blog.csdn.net/weixin_41924879/article/details/100852316

版权

Java 专栏收录该内容

128 篇文章 8 订阅

订阅专栏

Java高并发解决方案

分布式
分布式更多的一个概念是为了解决单个物理服务器容量和性能瓶颈问题而采用的优化手段。该领域需要解决的问题极多，在不同的技术层面上，又包括：分布式文件系统、分布式缓存、分布式数据库、分布式计算等，一些名词如Hadoop、zookeeper、MQ等都跟分布式有关。从理论上讲，分布式的实现有两种形式：
水平扩展：当一台机器扛不住流量时，就通过添加机器的方式，将流量平分到所有服务器上，所有机器都可以提供相当的服务；
垂直拆分：前端有多种查询需求时，一台机器顶不住，可以将不同的需求分发到不同的机器上，比如A机器处理余量查询的请求，B机器处理购买的请求。

高并发
由于分布式系统的问世，高并发（High Concurrency）通常是指通过设计保证系统能够同时并行处理很多请求。通俗来讲，高并发是指在同一个时间点，有很多用户同时的访问同一 API 接口或者 Url 地址。它经常会发生在有大活跃用户量，用户高聚集的业务场景中。

高并发是请求，指的是多个客户端同一时刻向服务端发送请求，它是一种现象。

相对于分布式来讲，高并发在解决的问题上会集中一些，其反应的是同时有多少量：比如在线抢票。高并发可以通过分布式技术去解决，将并发流量分到不同的物理服务器上。但除此之外，还可以有很多其他优化手段：比如使用缓存系统，将所有的静态内容放到CDN等；还可以使用多线程技术将一台服务器的服务能力最大化。

多线程
多线程是指从软件或者硬件上实现多个线程并发执行的技术，它更多的是解决CPU调度多个进程的问题，从而让这些进程看上去是同时执行（实际是交替运行的）。线程是程序中一个单一的顺序控制流程。在单个程序中同时运行多个线程完成不同的工作，称为多线程。

多线程是处理，指的是多个执行者处理同一类的任务，它有具体的实现。

多线程是指从软件或者硬件上实现多个线程并发执行的技术，它更多的是解决CPU调度多个进程的问题，从而让这些进程看上去是同时执行（实际是交替运行的）。

分布式、高并发、多线程这三个概念总是相伴而生，但侧重点又有不同。分布式是从物理资源的角度去将不同的机器组成一个整体对外服务，技术范围非常广且难度非常大，有了这个基础，高并发、高吞吐等系统很容易构建；高并发是从业务角度去描述系统的能力，实现高并发的手段可以采用分布式，也可以采用诸如缓存、CDN等，当然也包括多线程；多线程则聚焦于如何使用编程语言将CPU调度能力最大化。

响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。

吞吐量：单位时间内处理的请求数量。

QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。

并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

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

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

同步在一定程度上可以看做是单线程，这个线程请求一个方法后就待这个方法给他回复，否则不往下执行。
异步在一定程度上可以看做是多线程的(废话，一个线程怎么叫异步)，请求一个方法后，就不管了，继续执行其他的方法。
同步就是一件事一件事的做。异步就是，做一件事情，不做其他事情。

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

不可重复读
在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。

并行：多核CPU的情况，多个任务执行者并行处理任务。

并发：单个CPU的情况下，CPU间断性的执行多个任务。

原子性：不可分，从头执行到尾，不能被其他线程同时执行。

Java高并发解决方案

一、代码层面：锁优化措施、简化和减少事务

锁类型
可重入锁：在执行对象中所有同步方法不用再次获得锁

可中断锁：在等待获取锁过程中可中断

公平锁：按等待获取锁的线程的等待时间进行获取，等待时间长的具有优先获取锁权利

读写锁：对资源读取和写入的时候拆分为2部分处理，读的时候可以多线程一起读，写的时候必须同步地写

1、Synchronized 同步锁
synchronized是Java中的关键字，是一种同步锁。它修饰的对象有以下几种：

修饰一个代码块，被修饰的代码块称为同步语句块，其作用的范围是大括号{}括起来的代码，作用的对象是调用这个代码块的对象；
修饰一个方法，被修饰的方法称为同步方法，其作用的范围是整个方法，作用的对象是调用这个方法的对象；
修改一个静态的方法，其作用的范围是整个静态方法，作用的对象是这个类的所有对象；
修改一个类，其作用的范围是synchronized后面括号括起来的部分，作用主的对象是这个类的所有对象。

无论synchronized关键字加在方法上还是对象上，如果它作用的对象是非静态的，则它取得的锁是对象；如果synchronized作用的对象是一个静态方法或一个类，则它取得的锁是对类，该类所有的对象同一把锁。

每个对象只有一个锁（lock）与之相关联，谁拿到这个锁谁就可以运行它所控制的那段代码。

实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。

Synchronized与Lock的区别
在这里插入图片描述
lock()：获取锁，如果锁被暂用则一直等待

unlock()：释放锁

tryLock()：注意返回类型是boolean，如果获取锁的时候锁被占用就返回false，否则返回true

tryLock(long time, TimeUnit unit)：比起tryLock()就是给了一个时间期限，保证等待参数时间

lockInterruptibly()：用该锁的获得方式，如果线程在获取锁的阶段进入了等待，那么可以中断此线程，先去做别的事

2、ReentrantLock 重入锁
jdk中独占锁的实现除了使用关键字synchronized外,还可以使用ReentrantLock。虽然在性能上ReentrantLock和synchronized没有什么区别，但ReentrantLock相比synchronized而言功能更加丰富，使用起来更为灵活，也更适合复杂的并发场景。

ReentrantLock和synchronized都是独占锁,只允许线程互斥的访问临界区。但是实现上两者不同:synchronized加锁解锁的过程是隐式的,用户不用手动操作,优点是操作简单，但显得不够灵活。一般并发场景使用synchronized的就够了；ReentrantLock需要手动加锁和解锁,且解锁的操作尽量要放在finally代码块中,保证线程正确释放锁。ReentrantLock操作较为复杂，但是因为可以手动控制加锁和解锁过程,在复杂的并发场景中能派上用场。

ReentrantLock和synchronized都是可重入的。synchronized因为可重入因此可以放在被递归执行的方法上,且不用担心线程最后能否正确释放锁；而ReentrantLock在重入时要却确保重复获取锁的次数必须和重复释放锁的次数一样，否则可能导致其他线程无法获得该锁。

阻塞队列是利用ReentrantLock配合condition中的asigl、await方法实现的。

读写分离锁：读锁是利用到了共享模式，写锁是用到了独占模式，与synchronize相比，可以避免读读互排斥，降低了锁的范围。

Java并发库中ReetrantReadWriteLock实现了ReadWriteLock接口并添加了可重入的特性。
ReetrantReadWriteLock读写锁的效率明显高于synchronized关键字。
ReetrantReadWriteLock读写锁的实现中，读锁使用共享模式；写锁使用独占模式，换句话说，读锁可以在没有写锁的时候被多个线程同时持有，写锁是独占的。
ReetrantReadWriteLock读写锁的实现中，需要注意的，当有读锁时，写锁就不能获得；而当有写锁时，除了获得写锁的这个线程可以获得读锁外，其他线程不能获得读锁。

ReentrantLock继承AQS独占式方法，自旋锁的思想是：假设有1000个线程等待获取锁，是根据CAS及volatile 修改的状态变量进行判断的，当前线程的锁释放后，只会通知队列中的第一个线程去竞争锁，减少了并发冲突。（ZK的分布式锁，为了避免惊群效应，也使用了类似的方式：获取不到锁的线程只监听前一个节点）

实现锁的关键在于：

通过CAS操作与volatile变量互相配合，线程安全的修改锁标志位
基于CLH队列，实现锁的排队策略
公平锁、非公平锁都是静态内部类，区别就在于hasQueuedPredecessors这个方法，因此公平锁和非公平锁的区别在于，公平锁需要判断当前线程是否在等待队列首部的逻辑。

二、应用层面：缓存、队列、限流、熔断

三、数据库层面：分库分表、读写分离

数据库层面上比较典型的就是悲观锁（传统的物理锁）和乐观锁

悲观锁(Pessimistic Locking)
悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。

悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性。否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

一个典型的依赖数据库的悲观锁调用：

select * from count where name=”GEM” for update

这条 sql 语句锁定了 account 表中所有符合检索条件（ name=”GEM” ）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。

Hibernate 的悲观锁，也是基于数据库的锁机制实现。

下面的代码实现了对查询记录的加锁：

String hqlStr =”from User as user where user.name=’GEM’”;
Query query = session.createQuery(hqlStr);
query.setLockMode(“user”,LockMode.UPGRADE); // 加锁List userList = query.list();// 执行查询，获取数据

query.setLockMode 对查询语句中，特定别名所对应的记录进行加锁（我们为 User 类指定了一个别名 “user” ），这里也就是对返回的所有 user 记录进行加锁。

观察运行期 Hibernate 生成的 SQL 语句：

select tuser0_.id as id, tuser0_.name as name, tuser0_.group_idas group_id, tuser0_.user_type as user_type, tuser0_.sex as sexfrom t_user tuser0_ where (tuser0_.name=’Erica’ ) for update

这里 Hibernate 通过使用数据库的 for update 子句实现了悲观锁机制。

Hibernate 的加锁模式有：

LockMode.NONE ：无锁机制。
LockMode.WRITE ： Hibernate 在 Insert 和 Update 记录的时候会自动获取
LockMode.READ ： Hibernate 在读取记录的时候会自动获取。

以上这三种锁机制一般由 Hibernate 内部使用，如 Hibernate 为了保证 Update过程中对象不会被外界修改，会在 save 方法实现中自动为目标对象加上 WRITE 锁。

LockMode.UPGRADE ：利用数据库的 for update 子句加锁。
LockMode. UPGRADE_NOWAIT ： Oracle 的特定实现，利用 Oracle 的 for update nowait 子句实现加锁。

上面这两种锁机制是我们在应用层较为常用的，加锁一般通过以下方法实现：

Criteria.setLockModeQuery.setLockModeSession.lock

注意，只有在查询开始之前（也就是 Hiberate 生成 SQL 之前）设定加锁，才会真正通过数据库的锁机制进行加锁处理。否则，数据已经通过不包含 for update子句的 Select SQL 加载进来，所谓数据库加锁也就无从谈起。

乐观锁(Optimistic Locking)

相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。

乐观锁，大多是基于数据版本（Version ）记录机制实现。何谓数据版本？
即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

乐观锁机制避免了长事务中的数据库加锁开销，大大提升了大并发量下的系统整体性能表现。需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性。

为避免系统将脏数据更新到数据库中，需要将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开。 Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数据库的更新操作，利用 Hibernate 提供的透明化乐观锁实现，将大大提升我们的生产力。