1 成员变量、局部变量、类变量存储在内存的什么地方
1. 类变量(静态成员变量)
类变量是用static修饰符修饰,定义在方法外的变量,随着java进程产生和销毁在java7之前把静态变量存放于方法区,在java7时存放在堆中
2. 成员变量
成员变量是定义在类中,但是没有static修饰符修饰的变量,随着类的实例产生和销毁,是类实例的一部分
由于是实例的一部分,在类初始化的时候,从运行时常量池取出直接引用或者值,与初始化的对象一起放入堆中
3. 局部变量
局部变量是定义在类的方法中的变量
在所在方法被调用时放入虚拟机栈的栈帧中,栈顶是正在执行的方法,方法执行结束后从虚拟机栈中弹出,所以存放在虚拟机栈中
2 JVM8的内存结构
- 程序计数器(Program Counter Register)
程序计数器就是当前线程所执行的字节码的行号指示器,通过改变计数器的值,来选取下一行指令,通过他来实现跳转、循环、恢复线程等功能。
- 在任何时刻,一个处理器内核只能运行一个线程,多线程是通过线程轮流切换,分配时间来完成的,这就需要有一个标志来记住每个线程执行到了哪里,这里便需要到了程序计数器。
- 程序计数器是线程私有的,每个线程都已自己的程序计数器。
- 虚拟机栈(JVM Stacks)
虚拟机栈是线程私有的,随线程生灭。虚拟机栈描述的是线程中的方法的内存模型,每个方法被执行的时候,都会在虚拟机栈中同步创建一个栈帧(stack frame),方法被执行时入栈,执行完后出栈,每个栈帧的包含如下的内容
- 局部变量表: 局部变量表中存储着方法里的java基本数据类型(byte/boolean/char/int/long/double/float/short)以及对象的引用(注:这里的基本数据类型
指的是方法内的局部变量) - 操作数栈
- 动态连接
- 方法返回地址
虚拟机栈可能会抛出两种异常:
- 如果线程请求的栈深度大于虚拟机所规定的栈深度,则会抛出StackOverFlowError即栈溢出
- 如果虚拟机的栈容量可以动态扩展,那么当虚拟机栈申请不到内存时会抛出OutOfMemoryError即OOM内存溢出
产生StackOverFlowError的原因是: - 无限递归循环调用(最常见)。
- 执行了大量方法,导致线程栈空间耗尽。
- 方法内声明了海量的局部变量。
- 本地方法栈(Native Method Stacks)
本地方法栈与虚拟机栈的作用是相似的,都会抛出OutOfMemoryError和StackOverFlowError,都是线程私有的,主要的区别在于:
- 虚拟机栈执行的是java方法
- 本地方法栈执行的是native方法
- Java堆(Java Heap)
java堆是JVM内存中最大的一块,由所有线程共享, 是由垃圾收集器管理的内存区域,主要存放对象实例,当然由于java虚拟机的发展,堆中也多了许多东西,现在主要有:
- 对象实例
- 类初始化生成的对象
- 基本数据类型的数组也是对象实例
- 字符串常量池
- 字符串常量池原本存放于方法区,从jdk7开始放置于堆中。
- 字符串常量池存储的是string对象的直接引用,而不是直接存放的对象,是一张string table
- 静态变量
- 静态变量是有static修饰的变量,jdk7时从方法区迁移至堆中
- 线程分配缓冲区(Thread Local Allocation Buffer)
- 线程私有,但是不影响java堆的共性
- 增加线程分配缓冲区是为了提升对象分配时的效率
java堆既可以是固定大小的,也可以是可扩展的(通过参数-Xmx和-Xms设定),如果堆无法扩展或者无法分配内存时也会报OOM。
- 方法区(Method Area)
它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。
(1)类型信息:
对每个加载的 类型 (类class、接口interface、枚举enum、注解annotation),JVM必须在方法区中存储以下类型信息:
-
这个类型的完整有效名称(全名=包名.类名)
-
这个类型直接父类的完整有效名(对于interface或是java.lang. Object,都没有父类)
-
这个类型的修饰符( public, abstract,final的某个子集)
-
这个类型实现接口的一个有序列表。
(2) 域(Field)信息:
JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。域的相关信息包括如下内容: -
域名称
-
域类型
-
域修饰符(public,private,protected,static,final, volatile,transient的某个子集)
(3) 方法(Method)信息:JVM必须在方法区中保存类型的所有方法的相关信息以及方法的声明顺序。方法的相关信息包括:
-
方法名称
-
方法的返回类型(或void)
-
方法参数的数量和类型(按顺序)
-
方法的修饰符(public,private,protected,static,final,synchronized,native,abstract的一个子集)
-
方法的字节码(bytecodes)、操作数栈、局部变量表及大小( abstract和native方法除外)
-
异常表(abstract和 native方法除外)每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引
(4)静态变量(non-final的)
静态变量和类关联在一起,随着类的加载而加载,它们成为类数据在逻辑上的一部分。类变量被类的所有实例共享,即使没有类实例时你也可以访问它。
补充说明:被声明为final的静态变量的处理方法则不同,被static和final修饰的变量也称为全局变量,每个全局常量在编译的时候就会被赋值了。
public class Order {
public static int num = 10;
public static final int COUNT = 20;
}
(5)运行时常量池:
理解运行时常量池,需要了解字节码文件(ClassFile)中的常量池;方法区内部包含运行时常量池,字节码文件内部包含了常量池。
常量池:一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述信息外,还包含一项信息,那就是常量池( Constant Pool Table),包括各种字面量(数量值和字符串值)和对类型、域和方法的符号引用。常量池可以看做是一张表,虚拟机指令根据这张常量表,找到要执行的字面量、类名、方法名、参数类型等。
运行时常量池:
- 运行时常量池(Runtime Constant pool)是方法区的一部分。
- 常量池(Constant Pool Table)是class文件的一部分,用于存放编译期生成的各种字面量与符号引用,这部分内容将在类加载后存放到方法区的运行时常量池中。
- 在加载类和接口到虚拟机后,就会创建对应的运行时常量池。
- JVM为每个已加载的类型(类或接口)都维护一个运行时常量池,池中的数据项像数组项一样,是通过索引访问的。
- 运行时常量池中包含多种不同的常量,包括编译期就已经明确的数值字面量,也包括到运行期解析后才能够获得的方法或者字段引用。此时不再是常量池中的符号地址了,会转换为真实地址。运行时常量池,相对于Class文件中的常量池的另一重要特征是:具备动态性。比如String.intern()方法会动态地向池中增加内容
- 运行时常量池类似于传统编程语言中的符号表(symbol table),但是它所包含的数据比符号表要更加丰富。
- 如果构造类或接口的运行时常量池时,所需的内存空间超过了方法区所能提供的最大值,则JVM会抛出OutOfMemoryError异常。
-
直接内存(Direct Memory)
jdk1.4中加入了NIO(New Input/Putput)类,引入了一种基于通道(channel)与缓冲区(buffer)的新IO方式,它可以使用native函数直接分配堆外内存,然后通过存储在java堆中的DirectByteBuffer对象作为这块内存的引用进行操作,这样可以在一些场景下大大提高IO性能,避免了在java堆和native堆来回复制数据。
java 的 NIO 库允许 java 程序使用直接内存。直接内存是在 java 堆外的、直接向系统申请的内存空间。通常访问直接内存的速度会优于 java 堆。因此出于性能的考虑,读写频繁的场合可能会考虑使用直接内存。由于直接内存在 java 堆外,因此它的大小不会直接受限于 Xmx (虚拟机参数)指定的最大堆大小,但是系统内存是有限的, java 堆和直接内存的总和依然受限于操作系统能给出的最大内存。直接内存位于本地内存,不属于JVM内存,不受GC管理,但是也会在物理内存耗尽的时候报OOM。
注意:direct buffer不受GC影响,但是direct buffer归属的JAVA对象是在堆上且能够被GC回收的,一旦它被回收,JVM将释放direct buffer的堆外空间直接内存(Direct Memory)的特点:
- 直接内存并非 JVMS 定义的标准 Java 运行时内存。
- JDK1.4 加入了新的 NIO 机制,目的是防止 Java 堆 和 Native 堆之间往复的数据复制带来的性能损耗,此后 NIO 可以使用 Native 的方式直接在 Native 堆分配内存。
- 直接内存区域是全局共享的内存区域。
- 直接内存区域可以进行自动内存管理(GC),但机制并不完善。
- 本机的 Native 堆(直接内存) 不受 JVM 堆内存大小限制。可能出现 OutOfMemoryError 异常。
3 线程池
3.1 拒绝策略
线程池的拒绝策略
使用有界队列的时候,如果队列满了,提交任务到线程池的时候就会被拒绝。总体来说,任务被拒绝有两种情况:
(1)线程池已经被关闭。
(2)工作队列已满且 maximumPoolSize 已满。
无论以上哪种情况任务被拒,线程池都会调用 RejectedExecutionHandler 实例的rejectedExecution 方法。 RejectedExecutionHandler 是拒绝策略的接口, JUC 为该接口提供了以下几种实现:
- AbortPolicy:拒绝策略
- DiscardPolicy:抛弃策略
- DiscardOldestPolicy:抛弃最老任务策略
- CallerRunsPolicy:调用者执行策略
- 自定义策略
(1) AbortPolicy
使用该策略时,如果线程池队列满了则新任务被拒绝,并且会抛出 RejectedExecutionException异常。该策略是线程池的默认的拒绝策略。
(2) DiscardPolicy
该策略是 AbortPolicy 的 Silent(安静)版本,如果线程池队列满了,新任务会直接被丢掉,并且不会有任何异常抛出。
(3) DiscardOldestPolicy
抛弃最老任务策略,也就是说如果队列满了,会将最早进入队列的任务抛弃,从队列中腾出空间,再尝试加入队列。因为队列是队尾进队头出,队头元素是最老的,所以每次都是移除对头元素后再尝试入队。
(4) CallerRunsPolicy
调用者执行策略。在新任务被添加到线程池时,如果添加失败,那么提交任务线程会自己去执行该任务,不会使用线程池中的线程去执行新任务。
在以上的四种内置策略中,线程池默认的拒绝策略为 AbortPolicy,如果提交的任务被拒绝,线程池抛出 RejectedExecutionException 异常,该异常是非受检异常(运行时异常),很容易忘记捕获。如果关心任务被拒绝的事件,需要在提交任务时捕获 RejectedExecutionException 异常。
(5)自定义策略
如果以上拒绝策略都不符合需求,则可自定义一个拒绝策略,实现 RejectedExecutionHandler接口的 rejectedExecution 方法即可。
3.2 线程池的状态
线程池的 5 种状态,具体如下:
(1) RUNNING:线程池创建之后的初始状态,这种状态下可以执行任务。
(2)SHUTDOWN:该状态下线程池不再接受新任务,但是会将工作队列中的任务执行完毕。
(3) STOP:该状态下线程池不再接受新任务,也不会处理工作队列中的剩余任务,并且将会中断所有工作线程。
(4) TIDYING:该状态下所有任务都已终止或者处理完成,将会执行terminated( )钩子方法。
(5) TERMINATED:执行完terminated( )钩子方法之后的状态。
线程池的状态转换规则为:
(1)线程池创建之后状态为 RUNNING。
(2)执行线程池的 shutdown 实例方法,会使线程池状态从 RUNNING 转变为 SHUTDOWN。
(3)执行线程池的 shutdownNow 实例方法,会使线程池状态从 RUNNING 转变为 STOP。
(4)当线程池处于 SHUTDOWN 状态,执行器 shutdownNow 方法,会将其状态转变为 STOP状态。
(5)等待线程池的所有工作线程停止,工作队列清空之后,线程池状态会从 STOP 转变为TIDYING。
(6)执行完 terminated( ) 钩子方法之后,线程池状态从 TIDYING 转变为 TERMINATED 。