垃圾回收（GC）是JVM的一大杀器，它使程序员可以更高效地专注于程序的开发设计，而不用过多地考虑对象的创建销毁等操作。但是这并不是说程序员不需要了解GC。GC只是Java编程中一项自动化工具，任何一个工具都有它适用的范围，当超出它的范围的时候，可能它将不是那么自动，而是需要人工去了解与适应地适用。
拥有一定工作年限的程序员，在工作期间肯定会经常碰到像内存溢出、内存泄露、高并发的场景。这时候在应对这些问题或场景时，如果对GC不了解，很可能会成为个人的发展瓶颈。
接下来的两文将详细学习下JVM中垃圾回收（GC）的各个知识要点。本文先从GC的算法开始先了解，铺垫好基础，下一篇再详细讲JVM具体的GC实现。
垃圾回收，第一件事就是要搞清楚哪些东西是垃圾，而后才能对这些垃圾进行回收。
那么有什么办法识别对象是否为无用的垃圾呢？狭义地，怎么判断对象是否没被引用呢？
通常有以下两种算法去识别判断
之前《零基础带你看Spring源码——IOC控制反转》详细讲了Spring容器的初始化和加载的原理，后面《你真的完全了解Java动态代理吗？看这篇就够了》介绍了下JDK的动态代理。
基于这两者的实现上，这次来探索下Spring的AOP原理。虽然AOP是基于Spring容器和动态代理，但不了解这两者原理也丝毫不影响理解AOP的原理实现，因为大家起码都会用。
AOP，Aspect Oriented Programming，面向切面编程。在很多时候我们写一些功能的时候，不需要用到继承这么重的方法，例如对每个方法在执行前打log，在没有AOP的情况下，我们只能对每个方法都写一句打log的语句。如果是一个复杂点的功能，那么将会产生许多重复的代码，而且会对模块之间有更多的耦合。
然而，在AOP下，我们只需要通过特定的方法，就能直接切入代码，添加自定义的功能（后续再讲AOP里面的概念点）。
之前讲了《零基础带你看Spring源码——IOC控制反转》，本来打算下一篇讲讲Srping的AOP的，但是其中会涉及到Java的动态代理，所以先单独一篇来了解下Java的动态代理到底是什么，Java是怎么实现它的。
动态代理看起来好像是个什么高大上的名词，但其实并没有那么复杂，直接从字面就很容易理解。动态地代理，可以猜测一下它的含义，在运行时动态地对某些东西代理，代理它做了其他事情。先不去搞清楚这个动态代理真正的含义，我们来举个生动的例子来理解下它到底做了什么。
一个程序员Developer，他会开发code，他调试debug。
程序员有很多分类，其中有Java程序员JavaDeveloper，他会开发Java代码，会调试Java代码。
本章开始来学习下Spring的源码，看看Spring框架最核心、最常用的功能是怎么实现的。
网上介绍Spring，说源码的文章，大多数都是生搬硬推，都是直接看来的观点换个描述就放出来。这并不能说有问题，但没有从一个很好的、容易切入的角度去了解学习。博主来尝试抛弃一些所知，从使用上入手，步步回溯源码去了解学习。
很多人会混乱IOC和DI的两个概念，其实这两者是层面的不同。
具体的区别的区别：IOC是DI的原理。依赖注入是向某个类或方法注入一个值，其中所用到的原理就是控制反转。
所以说到操作层面的时候用DI，原理层的是说IOC，下文亦同。
对于DI最新使用方法，现在都是建议用Java注解去标识。但是相信笔者，不要用这种方式去看源码。笔者本来是想从Java注解入手去一步步看源码，debug看看发生什么了。但发现更多时间是在调SpringBoot和AOP的源码。在看了一天后，还是换一种思路吧，因为AOP是打算在下一章再讲的。
所以我用XML的方式，搭了一个最简单的Spring项目来学习其中IOC的源码。建议大家把代码拉下来，跟着笔者思路来一起看。
源码在此：https://github.com/Zack-Ku/spring-ioc-demo
maven的依赖,只添加了spring-context模板，用的是4.3.11版本
Java是一门多线程的语言，基本上生产环境的Java项目都离不开多线程。而线程则是其中最重要的系统资源之一，如果这个资源利用得不好，很容易导致程序低效率，甚至是出问题。
有以下场景，有个电话拨打系统，有一堆需要拨打的任务要执行，首先肯定是考虑多线程异步去执行。假如我每执行一个拨打任务都new一个Thread去执行，当同时有1万个任务需要执行的时候，那么就会新建1万个线程，加上线程各种初始销毁等操作，这个消耗是巨大的。而其实往往实现这些功能的时候，并不是完全需要实时马上完成，只是希望在可控范围内尽量提高执行的并发性能。
因此线程池技术应用而生，Java中最常用的线程池技术就是ThreadPoolExecutor。接下来就整体看看ThreadPoolExecutor的实现。