JAVA内存分配与管理是Java的核心技术之一,之前我们曾介绍过Java的内存管理与内存泄露以及Java渣滓回收方面的知识,明天我们再次深化Java核心,详细介绍一下Java在内存分配方面的知识。一般Java在内存分配时会触及到以下区域:
◆存放器:我们在程序中无法控制
◆栈:存放基本类型的数据和对象的援用,但对象自身不存放在栈中,而是存放在堆中
◆堆:存放用new产生的数据
◆静态域:存放在对象中用static定义的静态成员
◆常量池:存放常量
◆非RAM存储:硬盘等永久存储空间
Java内存分配中的栈
在函数中定义的一些基本类型的变量数据和对象的援用变量都在函数的栈内存中分配。 当在一段代码块定义一个变量时,Java就在栈中 为这个变量分配内存空间,当该变量退出该作用域后,Java会自动释放掉为该变量所分配的内存空间,该内存空间可以立刻被另作他用。
Java内存分配中的堆
堆内存用来存放由new创立的对象和数组。 在堆中分配的内存,由Java虚拟机的自动渣滓回收器来管理。
在堆中产生了一个数组或对象后,还可以 在栈中定义一个特殊的变量,让栈中这个变量的取值等于数组或对象在堆内存中的首地址,栈中的这个变量就成了数组或对象的援用变量。 援用变量就相当于是 为数组或对象起的一个名称,当前就可以在程序中运用栈中的援用变量来访问堆中的数组或对象。援用变量就相当于是为数组或许对象起的一个名称。
援用变量是普通的变量,定义时在栈中分配,援用变量在程序运行到其作用域之外后被释放。而数组和对象自身在堆中分配,即使程序 运行到运用 new 产生数组或许对象的语句所在的代码块之外,数组和对象自身占据的内存不会被释放,数组和对象在没有援用变量指向它的时候,才变为渣滓,不能在被运用,但仍 然占据内存空间不放,在随后的一个不确定的工夫被渣滓回收器收走(释放掉)。这也是 Java 比较占内存的缘由。
实践上,栈中的变量指向堆内存中的变量,这就是Java中的指针! 常量池 (constant pool)
常量池指的是在编译期被确定,并被保存在已编译的.class文件中的一些数据。除了包含代码中所定义的各种基本类型(如int、long等等)和对象型(如String及数组)的常量值(final)还包含一些以文本形式出现的符号援用,比如:
◆类和接口的全限定名;
◆字段的名称和描画符;
◆方法和名称和描画符。
虚拟机必须为每个被装载的类型维护一个常量池。常量池就是该类型所用到常量的一个有序集和,包括直接常量(string,integer和 floating point常量)和对其他类型,字段和方法的符号援用。
关于String常量,它的值是在常量池中的。而JVM中的常量池在内存当中是以表的形式存在的, 关于String类型,有一张固定长度的CONSTANT_String_info表用来存储文字字符串值,留意:该表只存储文字字符串值,不存储符号引 用。说到这里,对常量池中的字符串值的存储地位应该有一个比较明了的了解了。在程序执行的时候,常量池 会贮存在Method Area,而不是堆中。
堆与栈
Java的堆是一个运行时数据区,类的(对象从中分配空间。这些对象经过new、newarray、 anewarray和multianewarray等指令建立,它们不需要程序代码来显式的释放。堆是由渣滓回收来担任的,堆的优势是可以静态地分配内存 大小,生存期也不用事前通知编译器,由于它是在运行时静态分配内存的,Java的渣滓收集器会自动收走这些不再运用的数据。但缺点是,由于要在运行时静态 分配内存,存取速度较慢。
栈的优势是,存取速度比堆要快,仅次于存放器,栈数据可以共享。但缺点是,存在栈中的数据大小与生存期必须是 确定的,缺乏灵敏性。栈中次要存放一些基本类型的变量数据(int, short, long, byte, float, double, boolean, char)和对象句柄(援用)。
栈有一个很重要的特殊性,就是存在栈中的数据可以共享。假设我们同时定义:
inta=3;
intb=3;
编译器先处置int a = 3;首先它会在栈中创立一个变量为a的援用,然后查找栈中是否有3这个值,假如没找到,就将3存放进来,然后将a指向3。接着处置int b = 3;在创立完b的援用变量后,由于在栈中曾经有3这个值,便将b直接指向3。这样,就出现了a与b同时均指向3的情况。
这时,假如再令 a=4;那么编译器会重新搜索栈中是否有4值,假如没有,则将4存放进来,并令a指向4;假如曾经有了,则直接将a指向这个地址。因此a值的改动不会影响 到b的值。
要留意这种数据的共享与两个对象的援用同时指向一个对象的这种共享是不同的,由于这种情况a的修改并不会影响到b, 它是由编译器完成的,它有利于节省空间。而一个对象援用变量修改了这个对象的内部状态,会影响到另一个对象援用变量。文章由
斐格整理,收集辛苦,希望能保留出处,谢谢斑竹大哥。