java虚拟机代码缓存区,java虚拟机内存区域

java缓存是什么意思？ 文件放在哪？

Java的缓存机制是通过JVM(Java虚拟机)提供的运行时缓存来实现的，由于JVM是不跨平台的(Java的跨平台正是通过JVM的不跨平台来实现的)，所以JVM的缓存机制没有实现本地临时存储，因此你找不到所谓Java的缓存文件夹。这些问题你不用这么纠结，实在不清楚的话打电话问一下官方人员就清楚了。

相关问答

Q1: 如何查看java虚拟机堆内存的参数值

今天在加载一幅图片时，eclipse报出如下错误：

“Exception in thread "main" java.lang.OutOfMemoryError: Java heap space ”

google了一下原来是图片太大了。可以设置jvm堆的最大值来解决。

首先， 打开Eclipse软件，选择菜单栏run,在二级菜单中选择 Debug Configurations，然后：在弹出的窗口中选择（x）=arguments选项卡，VM arguments中输入所需要的内存最大占用量，比如输入-Xmx800m即可。

以下详细的介绍下jvm的几个参数：

“MyEclipse has detected that less than 5% of the 64MB of Perm Gen (Non-heap memory) space remains.”意思是说当前只有小于5%的非堆内存是空闲的。所以我们只要将这个值设置大一些就可以了。

提示中给出了设置的参数：

-vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M

这里有几个问题：

1. 各个参数的含义什么？

2. 为什么有的机器我将-Xmx和-XX:MaxPermSize都设置为512M之后Eclipse可以启动，而有些机器无法启动？

3. 为何将上面的参数写入到eclipse.ini文件Eclipse没有执行对应的设置？

下面我们一一进行回答

1. 各个参数的含义什么？

参数中-vmargs的意思是设置JVM参数，所以后面的其实都是JVM的参数了，我们首先了解一下JVM内存管理的机制，然后再解释每个参数代表的含义。

堆(Heap)和非堆(Non-heap)内存

按照官方的说法：“Java 虚拟机具有一个堆，堆是运行时数据区域，所有类实例和数组的内存均从此处分配。堆是在 Java 虚拟机启动时创建的。”“在JVM中堆之外的内存称为非堆内存(Non-heap memory)”。可以看出JVM主要管理两种类型的内存：堆和非堆。简单来说堆就是Java代码可及的内存，是留给开发人员使用的；非堆就是JVM留给自己用的，所以方法区、JVM内部处理或优化所需的内存(如JIT编译后的代码缓存)、每个类结构(如运行时常数池、字段和方法数据)以及方法和构造方法的代码都在非堆内存中。

堆内存分配

JVM初始分配的内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4。默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70% 时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。

非堆内存分配

JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。

JVM内存限制(最大值)

首先JVM内存限制于实际的最大物理内存(废话！呵呵)，假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，这个限制一般是2GB-3GB（一般来说Windows系统下为1.5G-2G，Linux系统下为2G-3G），而64bit以上的处理器就不会有限制了。

2. 为什么有的机器我将-Xmx和-XX:MaxPermSize都设置为512M之后Eclipse可以启动，而有些机器无法启动？

通过上面对JVM内存管理的介绍我们已经了解到JVM内存包含两种：堆内存和非堆内存，另外JVM最大内存首先取决于实际的物理内存和操作系统。所以说设置VM参数导致程序无法启动主要有以下几种原因：

1) 参数中-Xms的值大于-Xmx，或者-XX:PermSize的值大于-XX:MaxPermSize；

2) -Xmx的值和-XX:MaxPermSize的总和超过了JVM内存的最大限制，比如当前操作系统最大内存限制，或者实际的物理内存等等。说到实际物理内存这里需要说明一点的是，如果你的内存是1024MB，但实际系统中用到的并不可能是1024MB，因为有一部分被硬件占用了。

3. 为何将上面的参数写入到eclipse.ini文件Eclipse没有执行对应的设置？

那为什么同样的参数在快捷方式或者命令行中有效而在eclipse.ini文件中是无效的呢？这是因为我们没有遵守eclipse.ini文件的设置规则：

参数形如“项 值”这种形式，中间有空格的需要换行书写，如果值中有空格的需要用双引号包括起来。比如我们使用-vm C:\Java\jre1.6.0\bin\javaw.exe参数设置虚拟机，在eclipse.ini文件中要写成这样：

-vm

C:\Java\jre1.6.0\bin\javaw.exe

按照上面所说的，最后参数在eclipse.ini中可以写成这个样子：

-vmargs

-Xms128M

-Xmx512M

-XX:PermSize=64M

-XX:MaxPermSize=128M

实际运行的结果可以通过Eclipse中“Help”-“About Eclipse SDK”窗口里面的“Configuration Details”按钮进行查看。

另外需要说明的是，Eclipse压缩包中自带的eclipse.ini文件内容是这样的：

-showsplash

org.eclipse.platform

--launcher.XXMaxPermSize

256m

-vmargs

-Xms40m

-Xmx256m

其中–launcher.XXMaxPermSize（注意最前面是两个连接线）跟-XX:MaxPermSize参数的含义基本是一样的，我觉得唯一的区别就是前者是eclipse.exe启动的时候设置的参数，而后者是eclipse所使用的JVM中的参数。其实二者设置一个就可以了，所以这里可以把–launcher.XXMaxPermSize和下一行使用#注释掉。

Q2: java中可以实现缓冲区溢出攻击吗

不可以实现缓冲区溢出攻击；

纯java代码是不会有缓冲区溢出漏洞的,因为java中是全自动内存管理了,用户无法控制内存的分配与释放.

缓冲区溢出攻击是利用缓冲区溢出漏洞所进行的攻击行动。缓冲区溢出是一种非常普遍、非常危险的漏洞，在各种操作系统、应用软件中广泛存在。利用缓冲区溢出攻击，可以导致程序运行失败、系统关机、重新启动等后果。

缓冲区溢出是指当计算机向缓冲区内填充数据位数时超过了缓冲区本身的容量，溢出的数据覆盖在合法数据上。理想的情况是：程序会检查数据长度，而且并不允许输入超过缓冲区长度的字符。但是绝大多数程序都会假设数据长度总是与所分配的储存空间相匹配，这就为缓冲区溢出埋下隐患。

Q3: java中虚拟机的内存到底分为几类呢，网上说法挺多，能不能给个专业的

Java内存模型

主内存与工作内存

Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样底层细节。此处的变量与Java编程时所说的变量不一样，指包括了实例字段、静态字段和构成数组对象的元素，但是不包括局部变量与方法参数，后者是线程私有的，不会被共享。

Java内存模型中规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存（可以与前面将的处理器的高速缓存类比），线程的工作内存中保存了该线程使用到的变量到主内存副本拷贝，线程对变量的所有操作（读取、赋值）都必须在工作内存中进行，而不能直接读写主内存中的变量。不同线程之间无法直接访问对方工作内存中的变量，线程间变量值的传递均需要在主内存来完成，线程、主内存和工作内存的交互关系如下图所示

这里的主内存、工作内存与Java内存区域的Java堆、栈、方法区不是同一层次内存划分。

内存间交互操作

关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步到主内存之间的实现细节，Java内存模型定义了以下八种操作来完成：

· lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态。

· unlock（解锁）：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。

· read（读取）：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用

· load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。

· use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。

· assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。

· store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。

· write（写入）：作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中。

如果要把一个变量从主内存中复制到工作内存，就需要按顺寻地执行read和load操作，如果把变量从工作内存中同步回主内存中，就要按顺序地执行store和write操作。Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。也就是read和load之间，store和write之间是可以插入其他指令的，如对主内存中的变量a、b进行访问时，可能的顺序是read a，read b，load b， load a。Java内存模型还规定了在执行上述八种基本操作时，必须满足如下规则：

· 不允许read和load、store和write操作之一单独出现

· 不允许一个线程丢弃它的最近assign的操作，即变量在工作内存中改变了之后必须同步到主内存中。

· 不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中。

· 一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。

· 一个变量在同一时刻只允许一条线程对其进行lock操作，lock和unlock必须成对出现

· 如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值

· 如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一个被其他线程锁定的变量。

· 对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）。

重排序

在执行程序时为了提高性能，编译器和处理器经常会对指令进行重排序。重排序分成三种类型：

编译器优化的重排序。编译器在不改变单线程程序语义放入前提下，可以重新安排语句的执行顺序。

指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。

内存系统的重排序。由于处理器使用缓存和读写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

从Java源代码到最终实际执行的指令序列，会经过下面三种重排序：

为了保证内存的可见性，Java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。Java内存模型把内存屏障分为LoadLoad、LoadStore、StoreLoad和StoreStore四种：

同步机制

介绍volatile、synchronized和final

原子性、可见性与有序性

Java内存模型JMM解决了可见性和有序性的问题，而锁解决了原子性的问题。

可见性

指的是一个线程对变量的写操作对其他线程后续的读操作可见。由于现代CPU都有多级缓存，CPU的操作都是基于高速缓存的，而线程通信是基于内存的，这中间有一个Gap,可见性的关键还是在对变量的写操作之后能够在某个时间点显示地写回到主内存，这样其他线程就能从主内存中看到最新的写的值。volatile，synchronized(隐式锁), 显式锁，原子变量这些同步手段都可以保证可见性。

可见性底层的实现是通过加内存屏障实现的：

1. 写变量后加写屏障，保证CPU写缓冲区的值强制刷新回主内存

2. 读变量之前加读屏障，使缓存失效，从而强制从主内存读取变量最新值

写volatile变量 = 进入锁

读volatile变量 = 释放锁

有序性

指的是数据不相关的变量在并发的情况下，实际执行的结果和单线程的执行结果是一样的，不会因为重排序的问题导致结果不可预知。volatile, final, synchronized，显式锁都可以保证有序性。

有序性的语意有几层，

1. 最常见的就是保证多线程执行的串行顺序

2. 防止重排序引起的问题

3. 程序执行的先后顺序，比如JMM定义的一些Happens-before规则

重排序

的问题是一个单独的主题，常见的重排序有3个层面:

1. 编译级别的重排序，比如编译器的优化

2. 指令级重排序，比如CPU指令执行的重排序

3. 内存系统的重排序，比如缓存和读写缓冲区导致的重排序

原子性

是指某个(些)操作在语意上是原子的。比如读操作，写操作，CAS(compareand set)操作在机器指令级别是原子的，又比如一些复合操作在语义上也是原子的，如先检查后操作if(xxx== null){}

有个专有名词竞态条件来描述原子性的问题。

竞态条件(racing condition)是指某个操作由于不同的执行时序而出现不同的结果，比如先检查后操作。

volatile变量只保证了可见性，不保证原子性，比如a++这种操作在编译后实际是多条语句，比如先读a的值，再加1操作，再写操作，执行了3个原子操作，如果并发情况下，另外一个线程很有可能读到了中间状态，从而导致程序语意上的不正确。所以a++实际是一个复合操作。

加锁可以保证复合语句的原子性，sychronized可以保证多条语句在synchronized块中语意上是原子的。

显式锁保证临界区的原子性。

原子变量也封装了对变量的原子操作。

非阻塞容器也提供了原子操作的接口，比如putIfAbsent。