前言
面试过的人都知道，多线程高并发多线程是JAVA程序员无法规避的一个问题，无论哪个等级，这个问题都会被面试官问个遍。而且，对于程序员对于一些复杂场景，超长流程，采用多线程分治，会大大提高我们的响应速度和用户体验。虽然在设计上来说可能会有点复杂，但是我们程序员不就是为了应对复杂场景而生的么
通常我们遇到高并发的场景会怎么做谈到高并发，很多人估计会头疼，其实我也是。但是，仔细冷静下来想一想，我们其实解决高并发的套路无非就那么几种，我就目前我的理解来谈谈
1. 有锁的架构
在高并发中，最简单的就是加锁，其实锁也是有讲究滴！不同的场景用不同的锁，会给我们带来很多便利
1.1 悲观锁
1.1.1 简单粗暴的悲观锁
我们Java中最常见的互斥悲观锁就是synchronized关键字了，他可以保证同一时时间内只有一个线程拿到锁，执行同步代码块的内容。这个是最简单粗暴的，不管三七二十一先锁住，然后再执行代码块。和这个关键字相似的还有一个ReentrantLock可重入锁，这个是JUC包提供的一个锁，通过API层面，进行加锁和解锁，利用Java语言实现的，通过AQS队列实现线程等待排队持有锁的操作。这两个从效果上，性能上没有啥区别，都是悲观互斥锁，只是lock更加好操作和直观一点。到了高并发的时候，一样会出现线程上下文频繁切换，造成系统资源的浪费
1.1.2 稍作改变的读写锁
读写锁是引入了共享锁，再JUC包里面ReadWriteLock就是读写锁的实现。在高并发场景下，都多写少的场景里，比如我们的缓存，采用读写锁是非常合适不过的。因为读锁是共享锁，读锁是共享锁，所有读的操作，都共享一把读锁，没有竞争。写入锁是互斥锁，这个操作只允许一个线程在同一时间内持有。像缓存这种高读写少的情况，我们采用读写锁，会比起普通的互斥锁，会减少很多的竞争，大大提高响应速度
1.2 乐观锁
如果我们遇到那种读也很多，写也很多的场景，我们不管是读写锁，还是普通互斥锁，都没啥差别，这个时候，需要性能考虑，就需要乐观锁出场了。乐观锁就是比较并更新compareAndWarp,JUC里面提供的原子类就是基于这个api来实现的。只有当需要写入的值和预期值是一样的时候，才会执行写入操作。在JUC很多lock接口的实现类，里面有通过jdk底层调用本地方法来访问内存，通过本地方法来执行这个操作
但是乐观锁也是有问题的，在大量的读写的情况下，比如秒杀场景，如果采用乐观锁，会有很多线程调用compareAndWarp操作，如果需要百分之保证成功，内部需要自旋，自选过程中，必然会浪费很多CPU资源，如果同时大量的需求过来的情况下，会有很多线程进行自旋，造成CPU资源的严重浪费。这个时候，锁的存在就成了瓶颈，我们需要更加好的方案。所以，无锁的方案就出来了。
2.无锁的架构
无锁的架构要比有锁的架构要复杂的多，通常通过缓冲消息队列，第三方消息队列，还有一些高并发的框架实现。目前市面上高并发的框架Disruptor，这个框架是在JAVA内部实现了一个消息队列，通过生产者消费者的方式，来进行消息的处理。由于它内部采用了优化的设计，消费速度非常快。如果我们采用多生产者单消费者的模式，这样可以极大的避免读写不一致的问题。但是带来的新问题，就是比如我要对某个变量值做自增，生产者是不知道的，需要另外的方式来通知。 还有目前一个新兴的高并发的框架akka，这里面把所有的操作都封装成actor,通过actor来执行任务，在传统框架里面我们是通过调A对象调B对象的方法来执行某个任务，而在akka里面是通过A actor 发消息给B actor,来触发b actor的某个任务。actor的好处是轻量，占用资源少，同时akka帮我们维护了actor的周期，让我们原理线程的周期。假如类似秒杀任务，我把每个商品的数量的扣减，都交给一个actor去做，彼此之间通过邮件处理，这个时候，每个商品的数量的扣减也就不存在线程不安全的问题（我这这是个举例，现实未必是这样）。往往这种框架去除锁以后，这个时候需要追求最终一致性来保证数据结果。
总结
以上，我总结了目前的高并发的处理方案，这些高并发的处理方案，当然也只是粗略的总结了一下。我们遇到高并发场景时，首先得思考该场景的特点是读多写少还是读写均多，允许处理延迟多少。加锁的方案不是不可以，如果在允许响应时间内，用也不是不可以。一味的追求高性能，也会给程序带来复杂的设计成本和维护成本。
