Java Web系列文章汇总贴: Java Web知识总结汇总
JVM概述
JVM与JDK、JRE
- JDK(Java Develop Kit)：Java开发工具包，包括JRE，Java工具和Java基础类库
- JRE(Java Runtime Environment)：Java运行环境，包括JVM标准实现和Java核心类库
- JVM(Java Virtual Machine)：整个java实现跨平台的最核心的部分，能够运行以Java语言写的程序。
JVM-Java跨平台
JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。
Java语言的一个非常重要的特点就是与平台的无关性。而使用Java虚拟机是实现这一特点的关键。一般的高级语言如果要在不同的平台上运行，至少需要编译成不同的目标代码。而引入Java语言虚拟机后，Java语言在不同平台上运行时不需要重新编译。Java语言使用Java虚拟机屏蔽了与具体平台相关的信息，使得Java语言编译程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。Java虚拟机在执行字节码时，把字节码解释成具体平台上的机器指令执行。这就是Java的能够“一次编译，到处运行”的原因。
而且，JVM不仅为Java语言服务，可以运行Java语言编译的class文件，只要符合虚拟机规范，python等其他语言编译的class文件也可以在JVM上运行。
JVM体系结构与运行原理
Java语言写的源程序通过Java编译器，编译成与平台无关的‘字节码程序’(.class文件，也就是0，1二进制程序)，然后在OS之上的Java解释器中解释执行。
JVM内存模型
内存划分概览
内存区域
1、程序计数器：
此区域是一块较小的空间，可以看成是当前线程所执行的字节码的行号指示器。
为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。
如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是Native方法，这个计数器值则为空（Undefined）。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
2、虚拟机栈：
与程序计数器一样，Java虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧（Stack Frame)用于存储局部变量表(基本数据类型、对象引用指针等)、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
在Java虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出*Error异常；如果虚拟机栈可以动态扩展，如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常
3、本地方法栈
本地方法栈（Native Method Stack）与虚拟机栈所发挥的作用是非常相似的，它们之间的区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。
其异常类型和虚拟机栈一致。
4、方法区
方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。也可简单理解为永久代，其实只是因为虚拟机的实现上，也对这块区域进行了内存回收同一管理。
运行时常量池（Runtime Constant Pool）也是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。
根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。
5、直接内存
直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致OutOfMemoryError异常出现。
在JDK 1.4中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。
显然，本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，肯定还是会受到本机总内存（包括RAM以及SWAP区或者分页文件）大小以及处理器寻址空间的限制。此区域内存计算方式是，进程内存-堆内存-栈内存等，可以得到直接内存的可用大小。服务器管理员在配置虚拟机参数时，会根据实际内存设置-Xmx等参数信息，但经常忽略直接内存，使得各个内存区域总和大于物理内存限制（包括物理的和操作系统级的限制），从而导致动态扩展时出现OutOfMemoryError异常。
6、Java堆
对于大多数应用来说，Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。
这一点在Java虚拟机规范中的描述是：所有的对象实例以及数组都要在堆上分配。但是随着JIT编译器的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化发生，所有的对象都分配在堆上也渐渐变得不是那么“绝对”了。
Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC堆”（Garbage Collected Heap，幸好国内没翻译成“垃圾堆”）。从内存回收的角度来看，由于现在收集器基本都采用分代收集算法，所以Java堆中还可以细分为：新生代和老年代；再细致一点的有Eden空间、From Survivor空间、To Survivor空间等。从内存分配的角度来看，线程共享的Java堆中可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB）。不过无论如何划分，都与存放内容无关，无论哪个区域，存储的都仍然是对象实例，进一步划分的目的是为了更好地回收内存，或者更快地分配内存。
根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。
GC管理
GC管理的Java堆
内存区域：
默认内存比例：
GC机制
JVM分别对新生代和旧生代采用不同的垃圾回收机制
新生代的GC
新生代通常存活时间较短，因此基于复制算法来进行回收，所谓复制算法就是扫描出存活的对象，并复制到一块新的完全未使用的空间中，对应于新生代，就是在Eden和其中一个Survivor，复制到另一个之间Survivor空间中，然后清理掉原来就是在Eden和其中一个Survivor中的对象。并且将这些对象的年龄设置为1，以后对象在 Survivor 区每熬过一次 Minor GC，就将对象的年
龄 + 1，当对象的年龄达到某个值时 ( 默认是 15 岁，可以通过参数 -XX:MaxTenuringThreshold 来设定)，这些对象就会成为老年代。但这也不是一定的，对于一些较大的对象 ( 即需要分配一块较大的连续内存空间 ) 则是直接进入到老年代。
新生代采用空闲指针的方式来控制GC触发，指针保持最后一个分配的对象在新生代区间的位置，当有新的对象要分配内存时，用于检查空间是否足够，不够就触发GC。当连续分配对象时，对象会逐渐从eden到 survivor，最后到老年代。
老年代的GC
老年代与新生代不同，对象存活的时间比较长，比较稳定，因此采用标记（Mark）整理算法来进行回收，所谓标记就是扫描出存活的对象，然后再进行回收未被标记的对象，回收后对用空出的空间要么进行合并，要么标记出来便于下次进行分配，总之就是要减少内存碎片带来的效率损耗。
在执行机制上JVM提供了串行 GC（SerialMSC）、并行GC（parallelMSC）和并发GC（CMS），具体算法细节还有待进一步深入研究。
内存回收策略与GC算法
根节点可达性分析
垃圾收集器必须要完成两件事情：一个是能够正确的检测出垃圾对象，另一个是能够释放垃圾对象占用的内存空间。
只要某个对象不再被其他活动对象(指的是能够被一个根对象集合到达的对象)引用，那么就可以回收(根节点可达性分析)。
根对象集合中又都是些什么对象？
◎ 方法中局部变量区中对象的引用：如在前面的staticData方法中定义的lg和o等对象的引用就是根对象集合中的一个根对象，这些根对象直接存储在栈帧中的局部变量区中。
◎ Java操作栈中的对象引用：有些对象是直接在操作栈中持有的，所以操作栈肯定也包含根对象集合。
◎ 常量池中的对象引用：每个类都会包含一个常量池，这些常用池中也会包含很多对象引用，如表示类名的字符串就保存在堆中，那么常量池中只会持有这个字符串对象的引用。
◎ 本地方法中持有的对象引用：有些对象被传入本地方法中，但是这些对象还没有被释放。
◎ 类的Class对象：当每个类被JVM加载时都会创建一个代表这个类的唯一数据类型的Class对象，而这个Class对象也同样存放在堆中，当这个类不再被使用时，在方法区中类数据和这个Class对象同样需要被回收。
JVM在做垃圾回收时会检查堆中的所有对象是否都会被这些根对象直接或者间接引用，能够被引用的对象就是活动对象，否则就可以被垃圾收集器回收。
三种GC优缺点对比(优秀的硬件建议使用CMS)
| GC | 优点 | 缺点 |
|---|---|---|
| Serial Collector (串行) | 适合内存有限的情况 | 回收慢 |
| Parallel Collector (并行) | 效率高 | 当Heap过大时，应用程序暂停时间较长 |
| CMS Collector (并发) | Old区回收暂停时间短 | 产生内存碎片、整个GC耗时较长、比较耗CPU |
JVM调优总结
类加载机制
概述
class文件以字节流的形式被JVM加载，主要包括 加载 验证 准备 解析 初始化 使用 卸载 六个阶段，其中 验证 准备 解析 属于链接阶段，加载 主要是把字节流读取进来，验证 是 格式、是否有危害等合法性的检验，准备 是 ，解析 包括 类、成员、函数等的解析，初始化 为类的静态成员等赋初始值等，包括new 等场景会触发初始化。
双亲委派机制
类的加载机制是双亲委派加载，这样可以保证加载的统一性，对同一个类，保证是同一个加载器加载。具体机制是，加载一个类时，首先检查是否已经进行过，该类的加载，然后看自己父类，是否存在，存在则有父类加载，不存在则自己加载。当然，不同的加载器之间，不是继承，而是组合。
具体ClassLoader包括，BootstrapClassLoader c++编写，为JVM本身服务，加载JAVAhome/lib下的类，然后是ExtClassLoader，加载JAVAhome/lib/ext下的类，可以使用，下面是ApplicationClassLoader加载classpath下的文件。
双亲委派的好处：
- 保证安全性(用户自定义的java.util.String类等不会被加载，因为启动类加载器先加载JDK自身的String类，用户自定义的后加载，交给启动类加载器加载时，会被丢弃)
- 提高性能(保证类不会重复加载，提升性能)
双亲委派机制的破坏
如果系统类需要回调用户编写的类，可能就需要打破这种机制，通过自定义ClassLoader，设置加载器 可以做到。Tomcat 的类加载就是这样一种场景。
-
双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前–即JDK1.2发布之前。由于双亲委派模型是在JDK1.2之后才被引入的，而类加载器和抽象类java.lang.ClassLoader则是JDK1.0时候就已经存在，面对已经存在 的用户自定义类加载器的实现代码，Java设计者引入双亲委派模型时不得不做出一些妥协。为了向前兼容，JDK1.2之后的java.lang.ClassLoader添加了一个新的proceted方法findClass()，在此之前，用户去继承java.lang.ClassLoader的唯一目的就是重写loadClass()方法，因为虚拟在进行类加载的时候会调用加载器的私有方法loadClassInternal()，而这个方法的唯一逻辑就是去调用自己的loadClass()。JDK1.2之后已不再提倡用户再去覆盖loadClass()方法，应当把自己的类加载逻辑写到findClass()方法中，在loadClass()方法的逻辑里，如果父类加载器加载失败，则会调用自己的findClass()方法来完成加载，这样就可以保证新写出来的类加载器是符合双亲委派模型的。
-
双亲委派模型的第二次“被破坏”是这个模型自身的缺陷所导致的，双亲委派模型很好地解决了各个类加载器的基础类统一问题(越基础的类由越上层的加载器进行加载)，基础类之所以被称为“基础”，是因为它们总是作为被调用代码调用的API。但是，如果基础类又要调用用户的代码，那该怎么办呢。
这并非是不可能的事情，一个典型的例子便是JNDI服务，它的代码由启动类加载器去加载(在JDK1.3时放进rt.jar)，但JNDI的目的就是对资源进行集中管理和查找，它需要调用独立厂商实现部部署在应用程序的classpath下的JNDI接口提供者(SPI, Service Provider Interface)的代码，但启动类加载器不可能“认识”之些代码，该怎么办？
为了解决这个困境，Java设计团队只好引入了一个不太优雅的设计：线程上下文件类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个；如果在应用程序的全局范围内都没有设置过，那么这个类加载器默认就是应用程序类加载器。了有线程上下文类加载器，JNDI服务使用这个线程上下文类加载器去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载动作，这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型，但这也是无可奈何的事情。Java中所有涉及SPI的加载动作基本上都采用这种方式，例如JNDI,JDBC,JCE,JAXB和JBI等。 -
双亲委派模型的第三次“被破坏”是由于用户对程序的动态性的追求导致的，例如OSGi的出现。在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为网状结构。
相关：
Java双亲委派模型及被破坏
破坏双亲委派机制的那些事
Tomcat 类加载器之为何违背双亲委派模型
深入理解类加载机制