您现在的位置是：首页 > 原理深入 > Java面试总结Java面试总结
aop和分带收集
第十三双眼睛2019-05-17【Java面试总结】人已围观
简介springaop
JVM在程序运行过程当中，会创建大量的对象，这些对象，大部分是短周期的对象，小部分是长周期的对象，对于短周期的对象，需要频繁地进行垃圾回收以保证无用对象尽早被释放掉，对于长周期对象，则不需要频率垃圾回收以确保无谓地垃圾扫描检测。为解决这种矛盾，Sun JVM的内存管理采用分代的策略。
1）年轻代(Young Gen)：年轻代主要存放新创建的对象，内存大小相对会比较小，垃圾回收会比较频繁。年轻代分成1个Eden Space和2个Suvivor Space（命名为A和B）。当对象在堆创建时，将进入年轻代的Eden Space。垃圾回收器进行垃圾回收时，扫描Eden Space和A Suvivor Space，如果对象仍然存活，则复制到B Suvivor Space，如果B Suvivor Space已经满，则复制到Old Gen。同时，在扫描Suvivor Space时，如果对象已经经过了几次的扫描仍然存活，JVM认为其为一个持久化对象，则将其移到Old Gen。扫描完毕后，JVM将Eden Space和A Suvivor Space清空，然后交换A和B的角色（即下次垃圾回收时会扫描Eden Space和B Suvivor Space。这么做主要是为了减少内存碎片的产生。
我们可以看到：Young Gen垃圾回收时，采用将存活对象复制到到空的Suvivor Space的方式来确保尽量不存在内存碎片，采用空间换时间的方式来加速内存中不再被持有的对象尽快能够得到回收。
2）年老代(Tenured Gen)：年老代主要存放JVM认为生命周期比较长的对象（经过几次的Young Gen的垃圾回收后仍然存在），内存大小相对会比较大，垃圾回收也相对没有那么频繁（譬如可能几个小时一次）。年老代主要采用压缩的方式来避免内存碎片（将存活对象移动到内存片的一边，也就是内存整理）。当然，有些垃圾回收器（譬如CMS垃圾回收器）出于效率的原因，可能会不进行压缩。
3）持久代(Perm Gen)：持久代主要存放类定义、字节码和常量等很少会变更的信息。
不过总的说来，Java的GC算法感觉是业界最成熟的，目前很多其他语言或者框架也都支持GC了，但大多数都是只达到Java Serial gc这种层面，甚至分generation都未考虑。JDK7里面针对CMS进行了一种改进，会采用一种G1(Garbage-First Garbage Collection)的算法。实际上Garbage-First paper(PDF) 2004年已经出现。
JVM区域总体分两类，heap区和非heap区。heap区又分：Eden Space（伊甸园）、Survivor Space(幸存者区)、Tenured Gen（老年代-养老区）。 非heap区又分：Code Cache(代码缓存区)、Perm Gen（永久代）、Jvm Stack(java虚拟机栈)、Local Method Statck(本地方法栈)。
HotSpot虚拟机GC算法采用分代收集算法：
1、一个人（对象）出来（new 出来）后会在Eden Space（伊甸园）无忧无虑的生活，直到GC到来打破了他们平静的生活。GC会逐一问清楚每个对象的情况，有没有钱（此对象的引用）啊，因为GC想赚钱呀，有钱的才可以敲诈嘛。然后富人就会进入Survivor Space（幸存者区），穷人的就直接kill掉。
2、并不是进入Survivor Space（幸存者区）后就保证人身是安全的，但至少可以活段时间。GC会定期（可以自定义）会对这些人进行敲诈，亿万富翁每次都给钱，GC很满意，就让其进入了Genured Gen(养老区)。万元户经不住几次敲诈就没钱了，GC看没有啥价值啦，就直接kill掉了。
3、进入到养老区的人基本就可以保证人身安全啦，但是亿万富豪有的也会挥霍成穷光蛋，只要钱没了，GC还是kill掉。
分区的目的：新生区由于对象产生的比较多并且大都是朝生夕灭的，所以直接采用复制算法。而养老区生命力很强，则采用标记-清理算法，针对不同情况使用不同算法。
非heap区域中Perm Gen中放着类、方法的定义，JVM Stack区域放着方法参数、局域变量等的引用，方法执行顺序按照栈的先入后出方式。
简单来讲，JVM的内存回收过程是这样的：
对象在Eden Space创建，当Eden Space满了的时候，gc就把所有在Eden Space中的对象扫描一次，把所有有效的对象复制到第一个Survivor Space，同时把无效的对象所占用的空间释放。当Eden Space再次变满了的时候，就启动移动程序把Eden Space中有效的对象复制到第二个Survivor Space，同时，也将第一个Survivor Space中的有效对象复制到第二个Survivor Space。如果填充到第二个Survivor Space中的有效对象被第一个Survivor Space或Eden Space中的对象引用，那么这些对象就是长期存在的，此时这些对象将被复制到Permanent Generation。若垃圾收集器依据这种小幅度的调整收集不能腾出足够的空间，就会运行Full GC，此时JVM GC停止所有在堆中运行的线程并执行清除动作。
1.为什么会有年轻代
我们先来屡屡，为什么需要把堆分代？不分代不能完成他所做的事情么？其实不分代完全可以，分代的唯一理由就是优化GC性能。你先想想，如果没有分代，那我们所有的对象都在一块，GC的时候我们要找到哪些对象没用，这样就会对堆的所有区域进行扫描。而我们的很多对象都是朝生夕死的，如果分代的话，我们把新创建的对象放到某一地方，当GC的时候先把这块存“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。
2.年轻代中的GC
HotSpot JVM把年轻代分为了三部分：1个Eden区和2个Survivor区（分别叫from和to）。默认比例为8：1,为啥默认会是这个比例，接下来我们会聊到。一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。因为年轻代中的对象基本都是朝生夕死的(80%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。
在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。
3.一个对象的这一辈子
我是一个普通的Java对象，我出生在Eden区，在Eden区我还看到和我长的很像的小兄弟，我们在Eden区中玩了挺长时间。有一天Eden区中的人实在是太多了，我就被迫去了Survivor区的“From”区，自从去了Survivor区，我就开始漂了，有时候在Survivor的“From”区，有时候在Survivor的“To”区，居无定所。直到我18岁的时候，爸爸说我成人了，该去社会上闯闯了。于是我就去了年老代那边，年老代里，人很多，并且年龄都挺大的，我在这里也认识了很多人。在年老代里，我生活了20年(每次GC加一岁)，然后被回收。
我们知道，Spring 中 AOP 是一大核心技术，也是面试中经常会被问到的问题，最近我在网上也看到很多面试题，其中和 Spring AOP 相关的就有不少，这篇文章主要来总结下相关的技术点，希望对大家有用。
几个常见的问题
针对这一块的东西，一般下面几个问题面试官问的比较多：
* Spring AOP用的是哪种设计模式？
* 谈谈你对代理模式的理解？
* 静态代理和动态代理有什么区别？
* 如何实现动态代理？
* Spring AOP中用的是哪种代理技术？
如果这些问题都能回答的很流畅的话，说明对代理这一块的基本知识有一定的了解了。因为我们在实际开发中，写业务代码会更多，所以这一块的东西，大部分人可能知道个一二，但是如果让他们很有条理的表达出来，可能就不那么容易了。
什么是 Spring AOP？
一般面试官问到这个问题，面试者基本上都会回答：AOP 就是面向切面编程。其实这真的是句废话，这么回答真的没有任何意义。
或许你可以给面试官举个例子：歌星都有好多助理，歌星最重要的一件事就是唱歌，其他事他不用关注，比如唱歌前可能需要和其他人谈合作，还要布置场地，唱歌后还要收钱等等，这些统统交给他对应的助理去做。
也许哪一天，这个歌星做慈善，免费唱歌了，不收钱了，那么就可以把收钱这个助力给辞退了。这就是 AOP，每个人各司其职，灵活组合，达到一种可配置的、可插拔的程序结构。AOP 的实现原理就是代理模式。
在程序中也是如此，通过代理，可以详细控制访问某个或者某类对象的方法，在调用这个方法前做前置处理，调用这个方法后做后置处理。
什么是代理模式？
代理模式的核心作用就是通过代理，控制对对象的访问。它的设计思路是：定义一个抽象角色，让代理角色和真实角色分别去实现它。
真实角色：实现抽象角色，定义真实角色所要实现的业务逻辑，供代理角色调用。它只关注真正的业务逻辑，比如歌星唱歌。
代理角色：实现抽象角色，是真实角色的代理，通过真实角色的业务逻辑方法来实现抽象方法，并在前后可以附加自己的操作，比如谈合同，布置场地，收钱等等。
这就是代理模式的设计思路。代理模式分为静态代理和动态代理。静态代理是我们自己创建一个代理类，而动态代理是程序自动帮我们生成一个代理，我们就不用管了。下面我详细介绍一下这两种代理模式。
静态代理模式
就举明星唱歌这个例子，根据上面提供的设计思路，首先我们需要创建明星这个抽象角色：
/*** 明星接口类 * @author shengwu ni * @date 2018-12-07*/publicinterfaceStar {/** * 唱歌方法 */voidsing();}
静态代理需要创建真实角色和代理角色，分别实现唱歌这个接口，真实角色很简单，直接实现即可，因为真实角色的主要任务就是唱歌。
/*** 真实明星类 * @author shengwu ni * @date 2018-12-08*/publicclassRealStarimplementsStar{@Overridepublicvoidsing(){System.out.println("明星本人开始唱歌……"); }}
代理类就需要做点工作了，我们思考一下，代理只是在明星唱歌前后做一些准备和收尾的事，唱歌这件事还得明星亲自上阵，代理做不了。所以代理类里面是肯定要将真实的对象传进来。有了思路，我们将代理类写出来。
这里说一下 Proxy.newProxyInstance() 方法，该方法接收三个参数：第一个参数指定当前目标对象使用的类加载器,获取加载器的方法是固定的；第二个参数指定目标对象实现的接口的类型；第三个参数指定动态处理器，执行目标对象的方法时,会触发事件处理器的方法。网上针对第三个参数的写法都是 new 一个匿名类来处理，我这直接用的 Java8 里面的 lamda 表达式来写的，都一样。底层原理使用的是反射机制。接下来写一个客户端程序来测试下。
我们对 JDK 动态代理做一个简单的总结：相对于静态代理，JDK 动态代理大大减少了我们的开发任务，同时减少了对业务接口的依赖，降低了耦合度。JDK 动态代理是利用反射机制生成一个实现代理接口的匿名类，在调用具体方法前调用InvokeHandler 来处理。但是 JDK 动态代理有个缺憾，或者说特点：JDK 实现动态代理需要实现类通过接口定义业务方法。也就是说它始终无法摆脱仅支持 interface 代理的桎梏，因为它的设计就注定了这个遗憾。
CGLIB 动态代理
由上面的分析可知，JDK 实现动态代理需要实现类通过接口定义业务方法，那对于没有接口的类，如何实现动态代理呢，这就需要 CGLIB 了。
CGLIB 采用了非常底层的字节码技术，其原理是通过字节码技术为一个类创建子类，并在子类中采用方法拦截的技术拦截所有父类方法的调用，顺势织入横切逻辑。但因为采用的是继承，所以不能对final修饰的类进行代理。我们来写一个 CBLIB 代理类。
1）年轻代(Young Gen)：年轻代主要存放新创建的对象，内存大小相对会比较小，垃圾回收会比较频繁。年轻代分成1个Eden Space和2个Suvivor Space（命名为A和B）。当对象在堆创建时，将进入年轻代的Eden Space。垃圾回收器进行垃圾回收时，扫描Eden Space和A Suvivor Space，如果对象仍然存活，则复制到B Suvivor Space，如果B Suvivor Space已经满，则复制到Old Gen。同时，在扫描Suvivor Space时，如果对象已经经过了几次的扫描仍然存活，JVM认为其为一个持久化对象，则将其移到Old Gen。扫描完毕后，JVM将Eden Space和A Suvivor Space清空，然后交换A和B的角色（即下次垃圾回收时会扫描Eden Space和B Suvivor Space。这么做主要是为了减少内存碎片的产生。
我们可以看到：Young Gen垃圾回收时，采用将存活对象复制到到空的Suvivor Space的方式来确保尽量不存在内存碎片，采用空间换时间的方式来加速内存中不再被持有的对象尽快能够得到回收。
2）年老代(Tenured Gen)：年老代主要存放JVM认为生命周期比较长的对象（经过几次的Young Gen的垃圾回收后仍然存在），内存大小相对会比较大，垃圾回收也相对没有那么频繁（譬如可能几个小时一次）。年老代主要采用压缩的方式来避免内存碎片（将存活对象移动到内存片的一边，也就是内存整理）。当然，有些垃圾回收器（譬如CMS垃圾回收器）出于效率的原因，可能会不进行压缩。
3）持久代(Perm Gen)：持久代主要存放类定义、字节码和常量等很少会变更的信息。
不过总的说来，Java的GC算法感觉是业界最成熟的，目前很多其他语言或者框架也都支持GC了，但大多数都是只达到Java Serial gc这种层面，甚至分generation都未考虑。JDK7里面针对CMS进行了一种改进，会采用一种G1(Garbage-First Garbage Collection)的算法。实际上Garbage-First paper(PDF) 2004年已经出现。
JVM区域总体分两类，heap区和非heap区。heap区又分：Eden Space（伊甸园）、Survivor Space(幸存者区)、Tenured Gen（老年代-养老区）。 非heap区又分：Code Cache(代码缓存区)、Perm Gen（永久代）、Jvm Stack(java虚拟机栈)、Local Method Statck(本地方法栈)。
HotSpot虚拟机GC算法采用分代收集算法：
1、一个人（对象）出来（new 出来）后会在Eden Space（伊甸园）无忧无虑的生活，直到GC到来打破了他们平静的生活。GC会逐一问清楚每个对象的情况，有没有钱（此对象的引用）啊，因为GC想赚钱呀，有钱的才可以敲诈嘛。然后富人就会进入Survivor Space（幸存者区），穷人的就直接kill掉。
2、并不是进入Survivor Space（幸存者区）后就保证人身是安全的，但至少可以活段时间。GC会定期（可以自定义）会对这些人进行敲诈，亿万富翁每次都给钱，GC很满意，就让其进入了Genured Gen(养老区)。万元户经不住几次敲诈就没钱了，GC看没有啥价值啦，就直接kill掉了。
3、进入到养老区的人基本就可以保证人身安全啦，但是亿万富豪有的也会挥霍成穷光蛋，只要钱没了，GC还是kill掉。
分区的目的：新生区由于对象产生的比较多并且大都是朝生夕灭的，所以直接采用复制算法。而养老区生命力很强，则采用标记-清理算法，针对不同情况使用不同算法。
非heap区域中Perm Gen中放着类、方法的定义，JVM Stack区域放着方法参数、局域变量等的引用，方法执行顺序按照栈的先入后出方式。
简单来讲，JVM的内存回收过程是这样的：
对象在Eden Space创建，当Eden Space满了的时候，gc就把所有在Eden Space中的对象扫描一次，把所有有效的对象复制到第一个Survivor Space，同时把无效的对象所占用的空间释放。当Eden Space再次变满了的时候，就启动移动程序把Eden Space中有效的对象复制到第二个Survivor Space，同时，也将第一个Survivor Space中的有效对象复制到第二个Survivor Space。如果填充到第二个Survivor Space中的有效对象被第一个Survivor Space或Eden Space中的对象引用，那么这些对象就是长期存在的，此时这些对象将被复制到Permanent Generation。若垃圾收集器依据这种小幅度的调整收集不能腾出足够的空间，就会运行Full GC，此时JVM GC停止所有在堆中运行的线程并执行清除动作。
1.为什么会有年轻代
我们先来屡屡，为什么需要把堆分代？不分代不能完成他所做的事情么？其实不分代完全可以，分代的唯一理由就是优化GC性能。你先想想，如果没有分代，那我们所有的对象都在一块，GC的时候我们要找到哪些对象没用，这样就会对堆的所有区域进行扫描。而我们的很多对象都是朝生夕死的，如果分代的话，我们把新创建的对象放到某一地方，当GC的时候先把这块存“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。
2.年轻代中的GC
HotSpot JVM把年轻代分为了三部分：1个Eden区和2个Survivor区（分别叫from和to）。默认比例为8：1,为啥默认会是这个比例，接下来我们会聊到。一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。因为年轻代中的对象基本都是朝生夕死的(80%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。
在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。
3.一个对象的这一辈子
我是一个普通的Java对象，我出生在Eden区，在Eden区我还看到和我长的很像的小兄弟，我们在Eden区中玩了挺长时间。有一天Eden区中的人实在是太多了，我就被迫去了Survivor区的“From”区，自从去了Survivor区，我就开始漂了，有时候在Survivor的“From”区，有时候在Survivor的“To”区，居无定所。直到我18岁的时候，爸爸说我成人了，该去社会上闯闯了。于是我就去了年老代那边，年老代里，人很多，并且年龄都挺大的，我在这里也认识了很多人。在年老代里，我生活了20年(每次GC加一岁)，然后被回收。
我们知道，Spring 中 AOP 是一大核心技术，也是面试中经常会被问到的问题，最近我在网上也看到很多面试题，其中和 Spring AOP 相关的就有不少，这篇文章主要来总结下相关的技术点，希望对大家有用。
几个常见的问题
针对这一块的东西，一般下面几个问题面试官问的比较多：
* Spring AOP用的是哪种设计模式？
* 谈谈你对代理模式的理解？
* 静态代理和动态代理有什么区别？
* 如何实现动态代理？
* Spring AOP中用的是哪种代理技术？
如果这些问题都能回答的很流畅的话，说明对代理这一块的基本知识有一定的了解了。因为我们在实际开发中，写业务代码会更多，所以这一块的东西，大部分人可能知道个一二，但是如果让他们很有条理的表达出来，可能就不那么容易了。
什么是 Spring AOP？
一般面试官问到这个问题，面试者基本上都会回答：AOP 就是面向切面编程。其实这真的是句废话，这么回答真的没有任何意义。
或许你可以给面试官举个例子：歌星都有好多助理，歌星最重要的一件事就是唱歌，其他事他不用关注，比如唱歌前可能需要和其他人谈合作，还要布置场地，唱歌后还要收钱等等，这些统统交给他对应的助理去做。
也许哪一天，这个歌星做慈善，免费唱歌了，不收钱了，那么就可以把收钱这个助力给辞退了。这就是 AOP，每个人各司其职，灵活组合，达到一种可配置的、可插拔的程序结构。AOP 的实现原理就是代理模式。
在程序中也是如此，通过代理，可以详细控制访问某个或者某类对象的方法，在调用这个方法前做前置处理，调用这个方法后做后置处理。
什么是代理模式？
代理模式的核心作用就是通过代理，控制对对象的访问。它的设计思路是：定义一个抽象角色，让代理角色和真实角色分别去实现它。
真实角色：实现抽象角色，定义真实角色所要实现的业务逻辑，供代理角色调用。它只关注真正的业务逻辑，比如歌星唱歌。
代理角色：实现抽象角色，是真实角色的代理，通过真实角色的业务逻辑方法来实现抽象方法，并在前后可以附加自己的操作，比如谈合同，布置场地，收钱等等。
这就是代理模式的设计思路。代理模式分为静态代理和动态代理。静态代理是我们自己创建一个代理类，而动态代理是程序自动帮我们生成一个代理，我们就不用管了。下面我详细介绍一下这两种代理模式。
静态代理模式
就举明星唱歌这个例子，根据上面提供的设计思路，首先我们需要创建明星这个抽象角色：
/*** 明星接口类 * @author shengwu ni * @date 2018-12-07*/publicinterfaceStar {/** * 唱歌方法 */voidsing();}
静态代理需要创建真实角色和代理角色，分别实现唱歌这个接口，真实角色很简单，直接实现即可，因为真实角色的主要任务就是唱歌。
/*** 真实明星类 * @author shengwu ni * @date 2018-12-08*/publicclassRealStarimplementsStar{@Overridepublicvoidsing(){System.out.println("明星本人开始唱歌……"); }}
代理类就需要做点工作了，我们思考一下，代理只是在明星唱歌前后做一些准备和收尾的事，唱歌这件事还得明星亲自上阵，代理做不了。所以代理类里面是肯定要将真实的对象传进来。有了思路，我们将代理类写出来。
这里说一下 Proxy.newProxyInstance() 方法，该方法接收三个参数：第一个参数指定当前目标对象使用的类加载器,获取加载器的方法是固定的；第二个参数指定目标对象实现的接口的类型；第三个参数指定动态处理器，执行目标对象的方法时,会触发事件处理器的方法。网上针对第三个参数的写法都是 new 一个匿名类来处理，我这直接用的 Java8 里面的 lamda 表达式来写的，都一样。底层原理使用的是反射机制。接下来写一个客户端程序来测试下。
我们对 JDK 动态代理做一个简单的总结：相对于静态代理，JDK 动态代理大大减少了我们的开发任务，同时减少了对业务接口的依赖，降低了耦合度。JDK 动态代理是利用反射机制生成一个实现代理接口的匿名类，在调用具体方法前调用InvokeHandler 来处理。但是 JDK 动态代理有个缺憾，或者说特点：JDK 实现动态代理需要实现类通过接口定义业务方法。也就是说它始终无法摆脱仅支持 interface 代理的桎梏，因为它的设计就注定了这个遗憾。
CGLIB 动态代理
由上面的分析可知，JDK 实现动态代理需要实现类通过接口定义业务方法，那对于没有接口的类，如何实现动态代理呢，这就需要 CGLIB 了。
CGLIB 采用了非常底层的字节码技术，其原理是通过字节码技术为一个类创建子类，并在子类中采用方法拦截的技术拦截所有父类方法的调用，顺势织入横切逻辑。但因为采用的是继承，所以不能对final修饰的类进行代理。我们来写一个 CBLIB 代理类。
Tags：
很赞哦！ ()
文章评论
本站推荐
猜你喜欢
