JVM的类加载过程后端

每日一句如果可以，请让我们慢慢了解，慢慢喜欢。
每日一句 The frog in the well knows nothing of the great ocean.
井底之蛙，不知大海。
JVM 的类加载阶段 【JVM的类加载过程】JVM 的类加载分为五个阶段：
1. 加载：被虚拟机读入内存
2. 验证：验证 Class 字节流的数据是否遵守JVM的规定
3. 准备：正式为类变量（静态变量）分配内存并设置初始值，并非代码中设置的值
4. 解析：将常量池中的符号引用解析为直接引用
5. 初始化：真正执行类中定义的java代码
加载指 JVM 读取 class 文件，并且根据 Class 文件描述创建 java.lang.Class 对象的过程。
类加载过程主要包含将 Class 文件读取到运行时区域的方法区内，在堆中创建 java.lang.Class 对象，并封装类在方法区的数据结构的过程。
在读取 Class 文件是既可以通过文件的形式读取，也可以通过 jar 包、war 包读取，还可以通过代理自动生成 Class或其他方式读取
验证主要用于确保 Class 文件符合当前虚拟机的要求，保障虚拟机自身的安全，只有通过验证的 CLass 文件才能被 JVM 加载
准备主要工作是在方法区中为类变量分配内存空间并设置类中变量的初始值。
初始值指不同数据类型的默认值，这里需要注意 final 类型的变量和非final类型的变量在准备阶段的数据初始化过程不同
例如一个成员变量定义如下：
public static long value = https://www.it610.com/article/1000;
在以上代码中，静态变量 value 在准备阶段的初始值是0，将 value 设置为 1000 的动作是在对象初始化时完成的，因为 JVM 在编译阶段会将静态变量的初始化操作定义在构造器中。
public static final int value = https://www.it610.com/article/1000;
则JVM在编译阶段后会为final类型的变量value生成其对应的ConstantValue属性，虚拟机在准备阶段会根据ConstantValue属性将value赋值为1000。
总结：静态变量会赋两次初值，准备阶段赋零值，初始化时赋用户设定值，而final变量会在准备阶段一次性赋值完毕
解析 JVM 会将常量池中的符号引用替换为直接引用。
初始化主要通过执行类构造器的方法为类进行初始化。
方法是在编译阶段由编译器自动收集类中静态语句和变量的赋值操作组成的。JVM规定，只有在父类的方法都执行成功后，子类中的方法才可以被执行。
在一个类中既没有静态变量赋值操作也没有静态语句块时，编译器不会为该类生成方法。
在发生以下几种情况时，JVM不会执行类的初始化流程：
1. 常量在编译时会将其常量值存入使用该常量的类的常量池中，该过程不需要调用常量所在的类，因此，不会触发该常量类的初始化。
2. 在子类引用父类的静态字段时，不会触发子类的初始化，只会触发父类的初始化。
3. 定义对象数组，不会触发父类的初始化
4. 在使用类名获取 Class 对象时不会触发类的初始化
5. 在使用 Class.forName 加载指定的类时，可以通过 initialize 参数设置是否需要对类进行初始化
6. 在使用ClassLoader默认的loadClass方法加载类时不会触发该类的初始化。
美文佳句很多时候，事情的困境，常常是因为我们自己钻了牛角尖，此时，你需要做的就是改变。
完美主义者可以放下执念，允许自己有普通人都会犯的小迷糊；职场妈妈可以直面现实，一个人永远做不到家庭和事业的双百分；承担了过多工作任务的员工，可以尝试向上级反映，寻求资源或调整目标……这些，都是我们应当并可以作出的改变。
正如这句话所说：世界上从来都没有所谓的奇迹，命运一直都掌握在我们自己手里。想要改变自己的命运，最重要的就是改变自己。当你开始改变自己的时候，很多东西就跟着改变了。
下一次，当烦恼降临时，不妨试试从自身找找问题。调整努力的方向和节奏，学会给心灵松绑，你会发现：很多事，其实没什么大不了。
面试题 @RestController 和 @Controller 有什么区别？ @RestController 注解，在 @Controller 基础上，增加了 @ResponseBody 注解，更加适合目前前后端分离的架构下，提供 Restful API ，返回例如 JSON 数据格式。当然，返回什么样的数据格式，根据客户端的 "ACCEPT" 请求头来决定。
SpringMVC工作原理？

1. 客户端发送请求到前端控制器 DispatcherServlet 2. DispatcherServlet 收到请求后，调用 HandlerMapping 处理器映射器，请求获取 handler 3. 处理器映射器根据 url 找到具体的处理器，生成处理器对象以及处理器拦截器（如果有则生成）一并返回给 DispatcherServlet 4. DispatcherServlet 调用 HandlerAdapter 处理器适配器 5. HandlerAdapter 经过适配器调用具体处理器（Handler，也叫后端控制器） 6. Handler 执行完成返回 ModelAndView 7. HandlerAdaper 将 Handler 执行结果 ModelAndView 返回给 DispatcherServlet 8. DispatcherServlet 将 ModelAndView 传给 ViewResolver 视图解析器进行解析 9. ViewResolver 解析后返回具体 View 10. DispatcherServlet 对 view 进行渲染视图（即将模型数据填充至视图中） 11. DispatcherServlet 响应用户

HashMap、ConcurrentHashMap 和Hashtable有什么区别？


	HashMap	ConcurrentHashMap	Hashtable
线程是否安全，以及实现线程安全的方式	HashMap不安全	线程安全，ConcurrentHashMap JDK1.7底层采用分段锁，对整个桶数进行了分割分段（segment），每一把锁只锁容器其中一部分数据，提高并发访问率。 JDK 1.8 底层采用 Node数组 + 链表 + 红黑树的结构实现，并发控制使用了 synchronized 和 CAS 操作。	线程安全，底层采用synchronized 来保证线程安全，直接是方法级别的加锁， ConcurrentHashMap 虽然也是 synchronized 但它是对链表或者红黑树的头节点进行加锁，锁的粒度更小
底层工作原理	底层采用的是数组 + 链表	ConcurrentHashMap JDK 1.7 底层采用分段的数组 + 链表实现。 JDK 1.8 采用的是数组 + 链表/红黑树	底层采用的是数组 + 链表
空值问题	HashMap允许使用null值（key和value）都可以。但是这样的键只有一个，可以有一个或多个键所对应的值为null		HashTable不允许null值（key和value都不可以）
初始容量、扩容与默认负载因子	HashMap 默认初始大小 16，每次扩容 2n，默认负载因子是0。75		HashTable 默认初始大小为11，每次扩容 2n+1