Spring的循环依赖 假设对象A中有属性是对象B，对象B中也有属性是对象A，即A和B循环依赖。 1.创建对象A，调用A的构造，并把A保存下来。 2.然后准备注入对象A中的依赖，发现对象A依赖对象B，那么开始创建对象B。 3.调用B的构造，并把B保存下来。 4.然后准备注入B的构造，发现B依赖对象A，对象A之前已经创建了，直接获取A并把A注入B（注意此时的对象A还没有完全注入成功，对象A中的对象B还没有注入），于是B创建成功。 5.把创建成功的B注入A，于是A也创建成功了。 于是循环依赖就被解决了。
这个方法是Spring解决循环依赖的关键方法，在这个方法中，使用了三层列表来查询的方式，这三层列表分别是： singletonObjects earlySingletonObjects singletonFactories
在循环依赖出现时，对象往往会先进入singletonFactories，然后earlySingletonObjects（删除上一部），然后singletonObjects（删除上一部）。
方法首先从singletonObjects中获取对象，当Spring准备新建一个对象时，singletonObjects列表中是没有这个对象的，然后进入下一步。 earlySingletonObjects列表，这是个为了循环依赖而存在的列表，从名字就可以看到，是个预创建的对象列表，刚刚创建的对象在这个列表里一般也没有。 earlySingletonObjects也没有则从singletonFactories中获取，前面说到singletonFactories是对象保存的第一步，实际上对象初始化后，可能还没有注入对象的依赖，就把对象放入了这个列表
ReetrantLock和Synchronied的区别 相似点：这两个同步方式有很多相似之处，他们都是加锁方式同步，而且都是阻塞式同步，也就是说当一个线程获取对象锁之后，进入同步块，其他访问该同步块的线程都必须阻塞在该同步块外面等待，而进行线程阻塞和唤醒的代价是比较高的(操作系统需要在用户态和内核态之间来回切换，代价很高。
锁的细粒度和灵活度：很明显ReenTrantLock优于Synchronized 便利性：很明显Synchronized的使用方便简洁，并且由编译器去保证锁的加锁和释放锁，而ReentrantLock则需要手动声明加锁和释放锁的方法，finally 在Synchronized优化以前，synchronized的性能是比ReenTrantLock差很多的，但是自从Synchronized引入了偏向锁，轻量级锁（自旋锁）后，两者的性能就差不多了，在两种方法都可用的情况下，官方甚至建议使用synchronized，其实synchronized的优化我感觉就借鉴了ReenTrantLock中的CAS技术。都是试图在用户态就把加锁问题解决，避免进入内核态的线程阻塞。 1.Synchronized Synchronized经过编译后，会在同步块前后分别形成monitorenter和monitorexit两个字节码指令，在执行monitorenter指令时，首先要尝试获取对象锁，如果对象没有别锁定，或者当前已经拥有这个对象锁，把锁的计数器加1，相应的在执行monitorexit指令时，会将计数器减1，当计数器为0时，锁就被释放了。如果获取锁失败，那当前线程就要阻塞，直到对象锁被另一个线程释放为止。 2.ReentrantLock 2.1 等待可中断，持有锁的线程长期不释放的时候，正在等待的线程可以选择放弃等待，这相当于Synchronized来说可以避免出现死锁的情况。通过lock.lockInterruptibly()来实现这个机制。 2.2 公平锁，多个线程等待同一个锁时，必须按照申请锁的时间顺序获得锁，Synchronized锁非公平锁，ReentrantLock默认的构造函数是创建的非公平锁，可以通过参数true设为公平锁 锁绑定多个条件，一个ReentrantLock对象可以同时绑定对个对象。ReenTrantLock提供了一个Condition（条件）类 耗时长的命令造成阻塞 keys、sort等命令 在架构设计中，有“分流”一招，说的是将处理快的请求和处理慢的请求分离来开，否则，慢的影响到了快的，让快的也快不起来；这在redis的设计中体现的非常明显，redis的纯内存操作，epoll非阻塞IO事件处理，这些快的放在一个线程中搞定，而持久化，AOF重写、Master-slave同步数据这些耗时的操作就单开一个进程来处理，不要慢的影响到快的； 同样，既然需要使用keys这些耗时的操作，那么我们就将它们剥离出去，比如单开一个redis slave结点，专门用于keys、sort等耗时的操作，这些查询一般不会是线上的实时业务，查询慢点就慢点，主要是能完成任务 smembers命令 smembers命令用于获取集合全集，时间复杂度为O(N),N为集合中的数量； 如果一个集合中保存了千万量级的数据，一次取回也会造成事件处理线程的长时间阻塞； 解决方案： 和sort，keys等命令不一样，smembers可能是线上实时应用场景中使用频率非常高的一个命令，这里分流一招并不适合，我们更多的需要从设计层面来考虑； 在设计时，我们可以控制集合的数量，将集合数一般保持在500个以内； 比如原来使用一个键来存储一年的记录，数据量大，我们可以使用12个键来分别保存12个月的记录，或者365个键来保存每一天的记录，将集合的规模控制在可接受的范围； save命令 Bgsave fork产生的阻塞 在redis需要执行耗时的操作时，会新建一个进程来做，比如数据持久化bgsave： 开启RDB持久化后，当达到持久化的阈值，redis会fork一个新的进程来做持久化，采用了操作系统的copy-on-wirte写时复制策略，子进程与父进程共享Page。如果父进程的Page（每页4K）有修改，父进程自己创建那个Page的副本，不会影响到子进程； fork新进程时，虽然可共享的数据内容不需要复制，但会复制之前进程空间的内存页表，如果内存空间有40G（考虑每个页表条目消耗 8 个字节），那么页表大小就有80M，这个复制是需要时间的 还有： Master向slave首次同步数据：当master结点收到slave结点来的syn同步请求，会生成一个新的进程，将内存数据dump到文件上，然后再同步到slave结点中； AOF日志重写：使用AOF持久化方式，做AOF文件重写操作会创建新的进程做重写；（重写并不会去读已有的文件，而是直接使用内存中的数据写成归档日志）（查询数据库中的键归档为一条命令，最多包含64的value）； 解决方案： 为了应对大内存页表复制时带来的影响，有些可用的措施： 1. 控制每个redis实例的最大内存量； 2. 使用大内存页，默认内存页使用4KB，这样，当使用40G的内存时，页表就有80M；而将每个内存页扩大到4M，页表就只有80K；这样复制页表几乎没有阻塞，同时也会提高快速页表缓冲TLB（translation lookaside buffer）的命中率； 3： 使用物理机； 4： 杜绝新进程的产生，不使用持久化，不在主结点上提供查询；实现起来有以下方案： 1） 只用单机，不开持久化，不挂slave结点。 持久化造成的阻塞 执行持久化（AOF / RDB snapshot)对系统性能有较大影响，特别是服务器结点上还有其它读写磁盘的操作时（比如，应用服务和redis服务部署在相同结点上，应用服务实时记录进出报日志）；应尽可能避免在IO已经繁重的结点上开Redis持久化； 子进程持久化时，子进程的write和主进程的fsync冲突造成阻塞 在开启了AOF持久化的结点上，当子进程执行AOF重写或者RDB持久化时，出现了Redis查询卡顿甚至长时间阻塞的问题, 此时, Redis无法提供任何读写操作； 原因分析： Redis 服务设置了 appendfsync everysec, 主进程每秒钟便会调用 fsync(), 要求内核将数据”确实”写到存储硬件里. 但由于服务器正在进行大量IO操作, 导致主进程 fsync()/操作被阻塞, 最终导致 Redis 主进程阻塞. 解决方案： 设置 no-appendfsync-on-rewrite yes, 在子进程执行AOF重写时, 主进程不调用fsync()操作；注意, 即使进程不调用 fsync(), 系统内核也会根据自己的算法在适当的时机将数据写到硬盘(Linux 默认最长不超过 30 秒). 这个设置带来的问题是当出现故障时，最长可能丢失超过30秒的数据，而不再是1秒；
mysql的分库分表 MYSQL需要创建临时表，查询完毕后再删除这些临时表，所以，子查询的速度会受到一定的影响，这里多了一个创建和销毁临时表的过程。 3、如何分库分表 维度： 垂直拆分 垂直分库（根据业务不同与微服务类似单独服务对应单独库） 垂直分表 垂直分表是基于数据库中的”列”进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过”大表拆小表”，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销。另外数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了磁盘IO，从而提升了数据库性能。 拆分字段的操作建议在数据库设计阶段就做好。如果是在发展过程中拆分，则需要改写以前的查询语句，会额外带来一定的成本和风险，建议谨慎 垂直拆分优缺点： 优点： 解决业务系统层面的耦合，业务清晰 与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等 高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈 缺点： 部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度 依然存在单表数据量过大的问题（需要水平切分） 分布式事务处理复杂 水平拆分（根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。） 优缺点： 优点： 不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力 应用端改造较小，不需要拆分业务模块 “冷热数据分离”实现方案 缺点： 跨分片事务难以保证 跨分片的复杂查询如join关联查询 数据多次扩展难度和维护量极大
如何保证消息队列的幂等性
比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update 一下好吧。（高并发会有问题） 比如你是写 Redis，那没问题了，反正每次都是 set，天然幂等性。 比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的 id，类似订单 id 之类的东西，然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个 id 写 Redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。 比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据。 应对软件变化
Spring的AOP（动态代理和Aspectj） JDK: import java.lang.reflect.InvocationHandler; import java.lang.reflect.Method; import java.lang.reflect.Proxy;
public class MyProxy implements InvocationHandler {
private UserDao userDao; private MyAspect myAspect; public MyProxy(UserDao userDao, MyAspect myAspect) { this.userDao = userDao; this.myAspect = myAspect; } //创建代理对象 public Object create(){ ClassLoader classLoader = userDao.getClass().getClassLoader();// Class<?>[] interfaces, 被代理对象的实现接口 Class<?>[] interfaces = userDao.getClass().getInterfaces();
UserDao proxy = (UserDao) Proxy.newProxyInstance(classLoader,interfaces,this); return proxy; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {// 织入 advice 加入到 被代理对象方法之前或之后
// method就是调用的被代理对象的方法 //String methodName = method.getName(); // Object 被代理对象 myAspect.check(); method.invoke(userDao,args);//userDaoImpl.save(参数) myAspect.log();
return null; }}
Cglib package com.qst.spring.aop.dyanmicProxy.cglib;
import org.springframework.cglib.proxy.Enhancer; import org.springframework.cglib.proxy.MethodInterceptor; import org.springframework.cglib.proxy.MethodProxy;
import java.lang.reflect.Method; import java.util.concurrent.atomic.AtomicStampedReference;
public class MyProxy implements MethodInterceptor {
private T byProxy; private MyAspect myAspect; public MyProxy(T byProxy, MyAspect myAspect) { this.byProxy = byProxy; this.myAspect = myAspect; } public T create(){ // 通国Enhancer创建代理类 ---- Proxy Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(byProxy.getClass()); enhancer.setCallback(this); T proxy = (T)enhancer.create(); return proxy; } @Override public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {// Method method,调用的被代理对象方法
String methodName = method.getName(); if(methodName.equals("save")){ myAspect.check(); method.invoke(byProxy,objects); myAspect.log(); } return null; }}
CountDownlatch的用法 倒计时阻塞： package CountDownLatch;
import java.util.concurrent.CountDownLatch; import CountDownLatch.Player;
public class Test {
public static void main(String[] args) { CountDownLatch begin = new CountDownLatch(1); CountDownLatch end = new CountDownLatch(2); Thread thread = new Thread(new Player(begin, end)); thread.start();//end -1; Thread thread2 = new Thread(new Player2(begin, end)); thread2.start();//end -1 try{ System.out.println("the race begin"); begin.countDown(); end.await(); System.out.println("the race end"); }catch(Exception e){ e.printStackTrace(); } }}
java线程池ThreadPoolExecutor类使用详解 首先看下ThreadPoolExecutor的构造函数 public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler) { corePoolSize:指定了线程池中的线程数量，它的数量决定了添加的任务是开辟新的线程去执行，还是放到workQueue任务队列中去； maximumPoolSize:指定了线程池中的最大线程数量，这个参数会根据你使用的workQueue任务队列的类型，决定线程池会开辟的最大线程数量； keepAliveTime:当线程池中空闲线程数量超过corePoolSize时，多余的线程会在多长时间内被销毁； unit:keepAliveTime的单位 workQueue:任务队列，被添加到线程池中，但尚未被执行的任务；它一般分为直接提交队列、有界任务队列、无界任务队列、优先任务队列几种； threadFactory:线程工厂，用于创建线程，一般用默认即可； handler:拒绝策略；当任务太多来不及处理时，如何拒绝任务；
一、workQueue任务队列 上面我们已经介绍过了，它一般分为直接提交队列、有界任务队列、无界任务队列、优先任务队列； 1、直接提交队列：设置为SynchronousQueue队列，SynchronousQueue是一个特殊的BlockingQueue，它没有容量，没执行一个插入操作就会阻塞，需要再执行一个删除操作才会被唤醒，反之每一个删除操作也都要等待对应的插入操作。
public class ThreadPool { private static ExecutorService pool; public static void main( String[] args ) { //maximumPoolSize设置为2 ，拒绝策略为AbortPolic策略，直接抛出异常 pool = new ThreadPoolExecutor(1, 2, 1000, TimeUnit.MILLISECONDS, new SynchronousQueue(),Executors.defaultThreadFactory(),new ThreadPoolExecutor.AbortPolicy()); for(int i=0;i<3;i++) { pool.execute(new ThreadTask()); } } } public class ThreadTask implements Runnable{
public ThreadTask() { } public void run() { System.out.println(Thread.currentThread().getName()); }}
输出结果为
pool-1-thread-1 pool-1-thread-2 Exception in thread “main” java.util.concurrent.RejectedExecutionException: Task com.hhxx.test.ThreadTask@55f96302 rejected from java.util.concurrent.ThreadPoolExecutor@3d4eac69[Running, pool size = 2, active threads = 0, queued tasks = 0, completed tasks = 2] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.reject(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.execute(Unknown Source) at com.hhxx.test.ThreadPool.main(ThreadPool.java:17)
可以看到，当任务队列为SynchronousQueue，创建的线程数大于maximumPoolSize时，直接执行了拒绝策略抛出异常。 使用SynchronousQueue队列，提交的任务不会被保存，总是会马上提交执行。如果用于执行任务的线程数量小于maximumPoolSize，则尝试创建新的进程，如果达到maximumPoolSize设置的最大值，则根据你设置的handler执行拒绝策略。因此这种方式你提交的任务不会被缓存起来，而是会被马上执行，在这种情况下，你需要对你程序的并发量有个准确的评估，才能设置合适的maximumPoolSize数量，否则很容易就会执行拒绝策略； 2、有界的任务队列：有界的任务队列可以使用ArrayBlockingQueue实现，如下所示 pool = new ThreadPoolExecutor(1, 2, 1000, TimeUnit.MILLISECONDS, new ArrayBlockingQueue(10),Executors.defaultThreadFactory(),new ThreadPoolExecutor.AbortPolicy()); 使用ArrayBlockingQueue有界任务队列，若有新的任务需要执行时，线程池会创建新的线程，直到创建的线程数量达到corePoolSize时，则会将新的任务加入到等待队列中。若等待队列已满，即超过ArrayBlockingQueue初始化的容量，则继续创建线程，直到线程数量达到maximumPoolSize设置的最大线程数量，若大于maximumPoolSize，则执行拒绝策略。在这种情况下，线程数量的上限与有界任务队列的状态有直接关系，如果有界队列初始容量较大或者没有达到超负荷的状态，线程数将一直维持在corePoolSize以下，反之当任务队列已满时，则会以maximumPoolSize为最大线程数上限。 3、无界的任务队列：有界任务队列可以使用LinkedBlockingQueue实现，如下所示 pool = new ThreadPoolExecutor(1, 2, 1000, TimeUnit.MILLISECONDS, new LinkedBlockingQueue(),Executors.defaultThreadFactory(),new ThreadPoolExecutor.AbortPolicy()); 使用无界任务队列，线程池的任务队列可以无限制的添加新的任务，而线程池创建的最大线程数量就是你corePoolSize设置的数量，也就是说在这种情况下maximumPoolSize这个参数是无效的，哪怕你的任务队列中缓存了很多未执行的任务，当线程池的线程数达到corePoolSize后，就不会再增加了；若后续有新的任务加入，则直接进入队列等待，当使用这种任务队列模式时，一定要注意你任务提交与处理之间的协调与控制，不然会出现队列中的任务由于无法及时处理导致一直增长，直到最后资源耗尽的问题。 4、优先任务队列：优先任务队列通过PriorityBlockingQueue实现，下面我们通过一个例子演示下
public class ThreadPool { private static ExecutorService pool; public static void main( String[] args ) { //优先任务队列 pool = new ThreadPoolExecutor(1, 2, 1000, TimeUnit.MILLISECONDS, new PriorityBlockingQueue(),Executors.defaultThreadFactory(),new ThreadPoolExecutor.AbortPolicy());
for(int i=0;i<20;i++) { pool.execute(new ThreadTask(i)); } }} public class ThreadTask implements Runnable,Comparable{
private int priority; public int getPriority() { return priority; } public void setPriority(int priority) { this.priority = priority; } public ThreadTask() { } public ThreadTask(int priority) { this.priority = priority; } //当前对象和其他对象做比较，当前优先级大就返回-1，优先级小就返回1,值越小优先级越高 public int compareTo(ThreadTask o) { return this.priority>o.priority?-1:1; } public void run() { try { //让线程阻塞，使后续任务进入缓存队列 Thread.sleep(1000); System.out.println("priority:"+this.priority+",ThreadName:"+Thread.currentThread().getName()); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } }}
我们来看下执行的结果情况
priority:0,ThreadName:pool-1-thread-1 priority:9,ThreadName:pool-1-thread-1 priority:8,ThreadName:pool-1-thread-1 priority:7,ThreadName:pool-1-thread-1 priority:6,ThreadName:pool-1-thread-1 priority:5,ThreadName:pool-1-thread-1 priority:4,ThreadName:pool-1-thread-1 priority:3,ThreadName:pool-1-thread-1 priority:2,ThreadName:pool-1-thread-1 priority:1,ThreadName:pool-1-thread-1
大家可以看到除了第一个任务直接创建线程执行外，其他的任务都被放入了优先任务队列，按优先级进行了重新排列执行，且线程池的线程数一直为corePoolSize，也就是只有一个。 通过运行的代码我们可以看出PriorityBlockingQueue它其实是一个特殊的无界队列，它其中无论添加了多少个任务，线程池创建的线程数也不会超过corePoolSize的数量，只不过其他队列一般是按照先进先出的规则处理任务，而PriorityBlockingQueue队列可以自定义规则根据任务的优先级顺序先后执行。 二、拒绝策略 一般我们创建线程池时，为防止资源被耗尽，任务队列都会选择创建有界任务队列，但种模式下如果出现任务队列已满且线程池创建的线程数达到你设置的最大线程数时，这时就需要你指定ThreadPoolExecutor的RejectedExecutionHandler参数即合理的拒绝策略，来处理线程池"超载"的情况。ThreadPoolExecutor自带的拒绝策略如下： 1、AbortPolicy策略：该策略会直接抛出异常，阻止系统正常工作； 2、CallerRunsPolicy策略：如果线程池的线程数量达到上限，该策略会把任务队列中的任务放在调用者线程当中运行； 3、DiscardOledestPolicy策略：该策略会丢弃任务队列中最老的一个任务，也就是当前任务队列中最先被添加进去的，马上要被执行的那个任务，并尝试再次提交； 4、DiscardPolicy策略：该策略会默默丢弃无法处理的任务，不予任何处理。当然使用此策略，业务场景中需允许任务的丢失； 以上内置的策略均实现了RejectedExecutionHandler接口，当然你也可以自己扩展RejectedExecutionHandler接口，定义自己的拒绝策略，我们看下示例代码：
public class ThreadPool { private static ExecutorService pool; public static void main( String[] args ) { //自定义拒绝策略 pool = new ThreadPoolExecutor(1, 2, 1000, TimeUnit.MILLISECONDS, new ArrayBlockingQueue(5), Executors.defaultThreadFactory(), new RejectedExecutionHandler() { public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { System.out.println(r.toString()+“执行了拒绝策略”);
} }); for(int i=0;i<10;i++) { pool.execute(new ThreadTask()); } }} public class ThreadTask implements Runnable{ public void run() { try { //让线程阻塞，使后续任务进入缓存队列 Thread.sleep(1000); System.out.println(“ThreadName:”+Thread.currentThread().getName()); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); }
}}
输出结果：
com.hhxx.test.ThreadTask@33909752执行了拒绝策略 com.hhxx.test.ThreadTask@55f96302执行了拒绝策略 com.hhxx.test.ThreadTask@3d4eac69执行了拒绝策略 ThreadName:pool-1-thread-2 ThreadName:pool-1-thread-1 ThreadName:pool-1-thread-1 ThreadName:pool-1-thread-2 ThreadName:pool-1-thread-1 ThreadName:pool-1-thread-2 ThreadName:pool-1-thread-1
可以看到由于任务加了休眠阻塞，执行需要花费一定时间，导致会有一定的任务被丢弃，从而执行自定义的拒绝策略；
