谈谈Java内存管理
我的图书馆
谈谈Java内存管理
一. 背景知识
二. Jvm虚拟机内存简介
三. 垃圾收集
四. Java7、8带来的一些变化
对于一个Java程序员来说，大多数情况下的确是无需对内存的分配、释放做太多考虑，对Jvm也无需有多么深的理解的。但是在写程序的过程中却也往往因为这样而造成了一些不容易察觉到的内存问题，并且在内存问题出现的时候，也不能很快的定位并解决。因此，了解并掌握Java的内存管理是一个合格的Java程序员必需的技能，也只有这样才能写出更好的程序，更好地优化程序的性能。
一. 背景知识
根据网络可以找到的资料以及笔者能够打听到的消息，目前国内外著名的几个大型互联网公司的语言选型概括如下：
Google: c/c
python java js，不得不提的是Google贡献给java社区的guava包质量非常高。
Youtube、豆瓣: python
fackbook、yahoo、flickr、新浪：php(优化过的php)
网易、阿里、搜狐: java、php、node.js
Twitter: ruby-&java,之所以如此就在于与jvm相比，Ruby的runtime是非常慢的。并且ruby的应用比起java还是比较小众的。
可见，虽然最近这些年很多言论都号称java已死或者不久即死，但是Java的语言应用占有率一直居高不下。与高性能的c/c
相比，java具有gc机制，并且没有那让人望而生畏的指针，上手门槛相对较低；而与上手成本更低的php、ruby来说，又比这些脚本语言有性能上的优势(这里暂时忽略fb自己开发的php vm)。
对于Java来说，最终是要依靠字节码运行在jvm上的。目前，常见的jvm有以下几种：
Sun HotSpot
BEA Jrockit
Dalvik(Android)
其中以HotSpot应用最广泛。目前sun jdk的最新版本已经到了8，但鉴于新版的jdk使用并未普及，因此本文仅仅针对HotSpot虚拟机的jdk6来讲。
二. Jvm虚拟机内存简介
2.1 Java运行时内存区
Java的运行时内存组成如下图所示：
其中，对于这各个部分有一些是线程私有的，其他则是线程共享的。
线程私有的如下：
程序计数器
当前线程所执行的字节码的行号指示器
Java虚拟机栈
Java方法执行的内存模型，每个方法被执行时都会创建一个栈帧，存储局部变量表、操作栈、动态链接、方法出口等信息。
每个线程都有自己独立的栈空间
线程栈只存基本类型和对象地址
方法中局部变量在线程空间中
本地方法栈
Native方法服务。在HotSpot虚拟机中和Java虚拟机栈合二为一。
线程共享的如下：
存放对象实例，几乎所有的对象实例以及其属性都在这里分配内存。
存储已经被虚拟机加载的类信息、常量、静态变量、JIT编译后的代码等数据。
运行时常量池
方法区的一部分。用于存放编译期生成的各种字面量和符号引用。
NIO、Native函数直接分配的堆外内存。DirectBuffer引用也会使用此部分内存。
2.2 对象访问
Java是面向对象的一种编程语言，那么如何通过引用来访问对象呢？一般有两种方式：
通过句柄访问
此种方式也是HotSpot虚拟机采用的方式。
2.3 内存溢出
在JVM申请内存的过程中，会遇到无法申请到足够内存，从而导致内存溢出的情况。一般有以下几种情况：
虚拟机栈和本地方法栈溢出
StackOverflowError: 线程请求的栈深度大于虚拟机所允许的最大深度(循环递归)
OutOfMemoryError: 虚拟机在扩展栈是无法申请到足够的内存空间，一般可以通过不停地创建线程引起此种情况
Java堆溢出: 当创建大量对象并且对象生命周期都很长的情况下，会引发OutOfMemoryError
运行时常量区溢出：OutOfMemoryError:PermGen space，这里一个典型的例子就是String的intern方法，当大量字符串使用intern时，会触发此内存溢出
方法区溢出：方法区存放Class等元数据信息，如果产生大量的类(使用cglib)，那么就会引发此内存溢出，OutOfMemoryError:PermGen space，在使用Hibernate等框架时会容易引起此种情况。
三. 垃圾收集
3.1 理论基础
在通常情况下，我们掌握java的内存管理就是为了应对网站/服务访问慢，慢的原因一般有以下几点：
内存：垃圾收集占用cpu；放入了太多数据，造成内存泄露(java也是有这种问题的^_^)
I/O速度太慢
依赖的其他服务响应太慢
复杂的业务逻辑或者算法造成响应的缓慢
其中，垃圾收集对性能的影响一般有以下几个：
程序吞吐量显著下降
响应时间变慢
先来看垃圾收集的一些基本概念
Concurrent Collector:收集的同时可运行其他的工作进程
Parallel Collector: 使用多CPU进行垃圾收集
Stop-the-word(STW):收集时必须暂停其他所有的工作进程
Sticky-reference-count：对于使用“引用计数”（reference count）算法的GC，如果对象的计数器溢出，则起不到标记某个对象是垃圾的作用了，这种错误称为sticky-reference-count problem，通常可以增加计数器的bit数来减少出现这个问题的几率，但是那样会占用更多空间。一般如果GC算法能迅速清理完对象，也不容易出现这个问题。
Mutator：mutate的中文是变异，在GC中即是指一种JVM程序，专门更新对象的状态的，也就是让对象“变异”成为另一种类型，比如变为垃圾。
On-the-fly：用来描述某个GC的类型：on-the-fly reference count garbage collector。此GC不用标记而是通过引用计数来识别垃圾。
Generational gc：这是一种相对于传统的“标记-清理”技术来说，比较先进的gc，特点是把对象分成不同的generation，即分成几代人，有年轻的，有年老的。这类gc主要是利用计算机程序的一个特点，即“越年轻的对象越容易死亡”，也就是存活的越久的对象越有机会存活下去（姜是老的辣）。
牵扯到垃圾收集，还需要搞清楚吞吐量与响应时间的含义
吞吐量是对单位时间内完成的工作量的量度。如：每分钟的 Web 服务器请求数量
响应时间是提交请求和返回该请求的响应之间使用的时间。如：访问Web页面花费的时间
吞吐量与访问时间的关系很复杂，有时可能以响应时间为代价而得到较高的吞吐量，而有时候又要以吞吐量为代价得到较好的响应时间。而在其他情况下，一个单独的更改可能对两者都有提高。通常，平均响应时间越短，系统吞吐量越大；平均响应时间越长，系统吞吐量越小；
但是，系统吞吐量越大， 未必平均响应时间越短；因为在某些情况（例如，不增加任何硬件配置）吞吐量的增大，有时会把平均响应时间作为牺牲，来换取一段时间处理更多的请求。
针对于Java的垃圾回收来说，不同的垃圾回收器会不同程度地影响这两个指标。例如：并行的垃圾收集器，其保证的是吞吐量，会在一定程度上牺牲响应时间。而并发的收集器，则主要保证的是请求的响应时间。
对于GC(垃圾回收)的流程的基本描述如下：
找出堆中活着的对象
释放死对象占用的资源
定期调整活对象的位置
GC算法一般有以下几种：
Mark-Sweep 标记-清除
Mark-Sweep-Compact 标记-整理
Copying Collector 复制算法
从”GC roots”开始扫描(这里的roots包括线程栈、静态常量等)，给能够沿着roots到达的对象标记为”live”,最终所有能够到达的对象都被标记为”live”,而无法到达的对象则为”dead”。效率和存活对象的数量是线性相关的。
Sweep-清除
扫描堆，定位到所有”dead”对象，并清理掉。效率和堆的大小是线性相关的。
Compact-压缩
对于对象的清除，会产生一些内存碎片，这时候就需要对这些内存进行压缩、整理。包括：relocate(将存货的对象移动到一起，从而释放出连续的可用内存)、remap(收集所有的对象引用指向新的对象地址)。效率和存活对象的数量是线性相关的。
将内存分为”from”和”to”两个区域，垃圾回收时，将from区域的存活对象整体复制到to区域中。效率和存活对象的数量是线性相关的。
其中，Copy对比Mark-sweep
内存消耗：copy需要两倍的最大live set内存；mark-sweep则只需要一倍。
效率上：copy与live set成线性相关，效率高；mark-sweep则与堆大小线性相关，效率较低。
分代收集是目前比较先进的垃圾回收方案
对于分代收集，有以下几个相关理论
分代假设：大部分对象的寿命很短，“朝生夕死”，重点放在对年青代对象的收集，而且年青代通常只占整个空间的一小部分。
把年青代里活的很长的对象移动到老年代。
只有当老年代满了才去收集。
收集效率明显比不分代高。
HotSpot虚拟机的分代收集，分为一个Eden区、两个Survivor去以及Old Generation/Tenured区，其中Eden以及Survivor共同组成New Generatiton/Young space。
Eden区是分配对象的区域。
Survivor是minor/younger gc后存储存活对象的区域。
Tenured区域存储长时间存活的对象。
分代收集中典型的垃圾收集算法组合描述如下：
年青代通常使用Copy算法收集，会stop the world
老年代收集一般采用Mark-sweep-compact, 有可能会stop the world，也可以是concurrent或者部分concurrent。
3.2 HotSpot垃圾收集器
上图即为HotSpot虚拟机的垃圾收集器组成。
Serial收集器
-XX: UserSerialGC参数打开此收集器
Client模式下新生代默认的收集器。
较长的stop the world时间
简单而高效
此收集器的一个工作流程如下如所示：
ParNew收集器
-XX: UserParNewGC
UseConcuMarkSweepGC时默认开启
Serial收集器的多线程版本
默认线程数与CPU数目相同
-XX:ParrallelGCThreads指定线程数目
对比Serial收集器如下图所示：
Parallel Scavenge收集器
新生代并行收集器
采用Copy算法
主要关注的是达到可控制的吞吐量，“吞吐量优先”
-XX:MaxGCPauseMillis -XX:GCTimeRAtion两个参数精确控制吞吐量
-XX:UseAdaptiveSizePolicy GC自适应调节策略
Server模式的默认新生代收集器
Serial Old收集器
Serial的老年代版本
Client模式的默认老年代收集器
CMS收集器的后备预案，Concurrent Mode Failure时使用
-XX: UseSerialGC开启此收集器
Parallel Old收集器
-XX: UseParallelGC -XX: UseParallelOldGC启用此收集器
Server模式的默认老年代收集器
Parallel Scavenge的老年代版本，使用多线程和”mark-sweep”算法
关注点在吞吐量以及CPU资源敏感的场合使用
一般使用Parallel Scavenge
Parallel Old可以达到最大吞吐量保证
并发低停顿收集器
-XX:UseConcMarkSweepGC 开启CMS收集器，(默认使用ParNew作为年轻代收集器，SerialOld作为收集失败的垃圾收集器)
以获取最短回收停顿时间为目标的收集器，重视响应速度，希望系统停顿时间最短，会和互联网应用。
四个步骤：
初始标记 Stop the world: 只标记GC roots能直接关联到的对象，速度很快。
并发标记：进行GC roots tracing，与用户线程并发进行
重新标记 Stop the world：修正并发标记期间因程序继续运行导致变动的标记记录
对比serial old收集器如下图所示：
CMS有以下的缺点：
CMS是唯一不进行compact的垃圾收集器，当cms释放了垃圾对象占用的内存后，它不会把活动对象移动到老年代的一端
对CPU资源非常敏感。不会导致线程停顿，但会导致程序变慢，总吞吐量降低。CPU核越多越不明显
无法处理浮动垃圾。可能出现“concurrent Mode Failure”失败， 导致另一次full GC ,可以通过调整-XX:CMSInitiatingOccupancyFraction来控制内存占用达到多少时触发gc
大量空间碎片。这个可以通过设置-XX:UseCMSCompacAtFullCollection(是否在full gc时开启compact)以及-XX:CMSFullGCsBeforeCompaction(在进行compact前full gc的次数)
G1算法在Java6中还是试验性质的，在Java7中正式引入，但还未被广泛运用到生产环境中。它的特点如下：
使用标记-清理算法
不会产生碎片
可预测的停顿时间
化整为零：将整个Java堆划分为多个大小相等的独立区域
-XX: UseG1GC可以打开此垃圾回收器
-XX:MaxGCPauseMillis=200可以设置最大GC停顿时间，当然JVM并不保证一定能够达到，只是尽力。
3.3 调优经验
需要打开gc日志并读懂gc日志：-XX:PrintHeapAtGC -XX: PrintGCDetails -XX: PrintGCDateStamps
垃圾回收的最佳状态是只有young gc，也就是避免生命周期很长的对象的存在。
从young gc开始，尽量给年青代大点的内存，避免full gc
注意Survivor大小
注意内存墙：4G~5G
GC日志简介
第一个箭头：35592K-&K)，箭头指向的是新生段的内存占用情况；&- 第二个箭头：38508K-&K)，箭头指向的是回收后的内存占用情况。
垃圾收集停顿时间：0.0336
老年代使用建议
Parallel GC(-XX: UseParallel[Old]GC)
Parallel GC的minor GC时间是最快的， CMS的young gc要比parallel慢， 因为内存碎片
可以保证最大的吞吐量
确实有必要才改成CMS或G1(for old gen collections)
小对象allocate的代价很小，通常10个CPU指令；收集掉新对象也非常廉价；不用担心活的很短的小对象
大对象分配的代价以及初始化的代价很大；不同大小的大对象可能导致java堆碎片，尤其是CMS, ParallelGC 或 G1还好；尽量避免分配大对象
避免改变数据结构大小，如避免改变数组或array backed collections / containers的大小;对象构建（初始化）时最好显式批量定数组大小;改变大小导致不必要的对象分配，可能导致java堆碎片
对象池可能潜在的问题
增加了活对象的数量，可能增加GC时间
访问（多线程）对象池需要锁，可能带来可扩展性的问题
小心过于频繁的对象池访问
四. Java7、8带来的一些变化
Java7带来的内存方面的一个很大的改变就是String常量池从Perm区移动到了Heap中。调用String的intern方法时，如果存在堆中的对象，则会直接保存对象的引用，而不会重新创建对象。
Java7正式引入G1垃圾收集器用于替换CMS。
Java8中，取消掉了方法区(永久代)，使用“元空间”替代，元空间只与系统内存相关。
Java 8 update 20所引入的一个很棒的优化就是G1回收器中的字符串去重（String deduplication）。由于字符串(包括它们内部的char[]数组）占用了大多数的堆空间，这项新的优化旨在使得G1回收器能识别出堆中那些重复出现的字符串并将它们指向同一个内部的char[]数组，以避免同一个字符串的多份拷贝，那样堆的使用效率会变得很低。可以使用-XX: UseStringDeduplication这个JVM参数来试一下这个特性。
发表评论：
TA的最新馆藏[转]&2013年12月 Java大版内专家分月排行榜第二
2013年8月 Java大版内专家分月排行榜第三
2013年10月 总版技术专家分月排行榜第三
2014年3月 Java大版内专家分月排行榜第一2014年1月 Java大版内专家分月排行榜第一2013年12月 Java大版内专家分月排行榜第一2013年11月 Java大版内专家分月排行榜第一2013年10月 Java大版内专家分月排行榜第一
本帖子已过去太久远了，不再提供回复功能。Java内存分配、管理小结 -
- ITeye技术网站
想写这篇总结酝酿了有个来月了，却始终感觉还差点什么东西，一直未敢动笔。
最近两天连夜奋战，重新整理下前面查阅的资料、笔记，还是决定将它写出来。
现在提出几个问题，如果都能熟练回答的大虾，请您飘过.如以往一样，我是小菜，本文自然也是针对小菜阶层的总结。
首先是概念层面的几个问题：
Java中运行时内存结构有哪几种？
Java中为什么要设计堆栈分离?
Java多线程中是如何实现数据共享的？
Java反射的基础是什么？
然后是运用层面：
引用类型变量和对象的区别？
什么情况下用局部变量，什么情况下用成员变量？
数组如何初始化？声明一个数组的过程中，如何分配内存？
声明基本类型数组和声明引用类型的数组，初始化时，内存分配机制有什么区？
在什么情况下，我们的方法设计为静态化，为什么？（上次胡老师问文奇，问的哑口无言，当时想回答，却老感觉表述不清楚，这里也简单说明一下）
好了，问题提完了，如果您都能一眼看出答案，那么，没有必要再浪费您宝贵的时间看下去了。
如果您还不太明白，请跟随我一路走下去。
Java中运行时内存结构
1.1 方法区：
方法区是系统分配的一个内存逻辑区域，是JVM在装载类文件时，用于存储类型信息的(类的描述信息)。
方法区存放的信息包括：
1.1.1类的基本信息：
每个类的全限定名
每个类的直接超类的全限定名(可约束类型转换)
该类是类还是接口
该类型的访问修饰符
直接超接口的全限定名的有序列表
1.1.2已装载类的详细信息：
运行时常量池：
在方法区中，每个类型都对应一个常量池，存放该类型所用到的所有常量，常量池中存储了诸如文字字符串、final变量值、类名和方法名常量。它们以数组形式通过索引被访问，是外部调用与类联系及类型对象化的桥梁。（存的可能是个普通的字符串，然后经过常量池解析，则变成指向某个类的引用）
字段信息：
字段信息存放类中声明的每一个字段的信息，包括字段的名、类型、修饰符。
字段名称指的是类或接口的实例变量或类变量，字段的描述符是一个指示字段的类型的字符串，如private A a=则a为字段名，A为描述符，private为修饰符
方法信息：
类中声明的每一个方法的信息，包括方法名、返回值类型、参数类型、修饰符、异常、方法的字节码。
(在编译的时候，就已经将方法的局部变量、操作数栈大小等确定并存放在字节码中，在装载的时候，随着类一起装入方法区。)
在运行时，JVM从常量池中获得符号引用，然后在运行时解析成引用项的实际地址，最后通过常量池中的全限定名、方法和字段描述符，把当前类或接口中的代码与其它类或接口中的代码联系起来。
静态变量：
这个没什么好说的，就是类变量，类的所有实例都共享，我们只需知道，在方法区有个静态区，静态区专门存放静态变量和静态块。
到类classloader的引用：到该类的类装载器的引用。
到类class 的引用：虚拟机为每一个被装载的类型创建一个class 实例，用来代表这个被装载的类。
由此我们可以知道反射的基础：
在装载类的时候，加入方法区中的所有信息，最后都会形成Class类的实例，代表这个被装载的类。方法区中的所有的信息，都是可以通过这个Class类对象反射得到。我们知道对象是类的实例，类是相同结构的对象的一种抽象。同类的各个对象之间，其实是拥有相同的结构（属性），拥有相同的功能（方法），各个对象的区别只在于属性值的不同。
同样的，我们所有的类，其实都是Class类的实例，他们都拥有相同的结构-----Field数组、Method数组。而各个类中的属性都是Field属性的一个具体属性值，方法都是Method属性的一个具体属性值。
在运行时，JVM从常量池中获得符号引用，然后在运行时解析成引用项的实际地址，最后通过常量池中的全限定名、方法和字段描述符，把当前类或接口中的代码与其它类或接口中的代码联系起来。
1.2 Java栈
JVM栈是程序运行时单位，决定了程序如何执行，或者说数据如何处理。
在Java中，一个线程就会有一个线程的JVM栈与之对应，因为不过的线程执行逻辑显然不同，因此都需要一个独立的JVM栈来存放该线程的执行逻辑。
对方法的调用：
Java栈内存，以帧的形式存放本地方法的调用状态，包括方法调用的参数、局部变量、中间结果等（方法都是以方法帧的形式存放在方法区的），每调用一个方法就将对应该方法的方法帧压入Java 栈，成为当前方法帧。当调用结束(返回)时，就弹出该帧。
这意味着：
在方法中定义的一些基本类型的变量和引用变量都在方法的栈内存中分配。当在一段代码块定义一个变量时，Java 就在栈中为这个变量分配内存空间，当超过变量的作用域后（方法执行完成后），Java 会自动释放掉为该变量所分配的内存空间，该内存空间可以立即被另作它用。--------同时，因为变量被释放，该变量对应的对象，也就失去了引用，也就变成了可以被gc对象回收的垃圾。
因此我们可以知道成员变量与局部变量的区别：
局部变量，在方法内部声明，当该方法运行完时，内存即被释放。成员变量，只要该对象还在，哪怕某一个方法运行完了，还是存在。从系统的角度来说，声明局部变量有利于内存空间的更高效利用（方法运行完即回收）。成员变量可用于各个方法间进行数据共享。
Java 栈内存的组成：局部变量区、操作数栈、帧数据区组成。（1）：局部变量区为一个以字为单位的数组，每个数组元素对应一个局部变量的值。调用方法时，将方法的局部变量组成一个数组，通过索引来访问。若为非静态方法，则加入一个隐含的引用参数this,该参数指向调用这个方法的对象。而静态方法则没有this参数。因此，对象无法调用静态方法。
由此，我们可以知道，方法什么时候设计为静态，什么时候为非静态？
前面已经说过，对象是类的一个实例，各个对象结构相同，只是属性不同。而静态方法是对象无法调用的。所以，静态方法适合那些工具类中的工具方法，这些类只是用来实现一些功能，也不需要产生对象，通过设置对象的属性来得到各个不同的个体。
（2）：操作数栈也是一个数组，但是通过栈操作来访问。所谓操作数是那些被指令操作的数据。当需要对参数操作时如a=b+c,就将即将被操作的参数压栈，如将b 和c 压栈，然后由操作指令将它们弹出，并执行操作。虚拟机将操作数栈作为工作区。（3）：帧数据区处理常量池解析，异常处理等
1.3 java堆
java的堆是一个运行时的数据区，用来存储数据的单元，存放通过new关键字新建的对象和数组，对象从中分配内存。
在堆中声明的对象，是不能直接访问的，必须通过在栈中声明的指向该引用的变量来调用。引用变量就相当于是为数组或对象起的一个名称，以后就可以在程序中使用栈中的引用变量来访问堆中的数组或对象。
由此我们可以知道,引用类型变量和对象的区别:
声明的对象是在堆内存中初始化的， 真正用来存储数据的。不能直接访问。
引用类型变量是保存在栈当中的，一个用来引用堆中对象的符号而已（指针）。
堆与栈的比较：JAVA堆与栈都是用来存放数据的，那么他们之间到底有什么差异呢？既然栈也能存放数据，为什么还要设计堆呢？
1.从存放数据的角度:
前面我们已经说明:
栈中存放的是基本类型的变量or引用类型的变量
堆中存放的是对象or数组对象.
在栈中，引用变量的大小为32位，基本类型为1-8个字节。
但是对象的大小和数组的大小是动态的，这也决定了堆中数据的动态性，因为它是在运行时动态分配内存的，生存期也不必在编译时确定，Java 的垃圾收集器会自动收走这些不再使用的数据。
2.从数据共享的角度:
1).在单个线程类，栈中的数据可共享
例如我们定义：
编译器先处理int a = 3；首先它会在栈中创建一个变量为a 的引用，然后查找栈中是否有3 这个值，如果没找到，就将3 存放进来，然后将a 指向3。接着处理int b = 3；在创建完b 的引用变量后，因为在栈中已经有3这个值，便将b 直接指向3。这样，就出现了a 与b 同时均指向3的情况。
而如果我们定义：
Integer a=new Integer(3);//(1)
Integer b=new Integer(3);//(2)
这个时候执行过程为：在执行(1)时，首先在栈中创建一个变量a，然后在堆内存中实例化一个对象，并且将变量a指向这个实例化的对象。在执行(2)时，过程类似，此时，在堆内存中，会有两个Integer类型的对象。
2).在进程的各个线程之间，数据的共享通过堆来实现
例：那么，在多线程开发中，我们的数据共享又是怎么实现的呢？
如图所示，堆中的数据是所有线程栈所共享的，我们可以通过参数传递，将一个堆中的数据传入各个栈的工作内存中，从而实现多个线程间的数据共享
（多个进程间的数据共享则需要通过网络传输了。）
3.从程序设计的的角度:
从软件设计的角度看，JVM栈代表了处理逻辑，而JVM堆代表了数据。这样分开，使得处理逻辑更为清晰。分而治之的思想。这种隔离、模块化的思想在软件设计的方方面面都有体现。
4.值传递和引用传递的真相
有了以上关于栈和堆的种种了解后，我们很容易就可以知道值传递和引用传递的真相：
1.程序运行永远都是在JVM栈中进行的，因而参数传递时，只存在传递基本类型和对象引用的问题。不会直接传对象本身。
但是传引用的错觉是如何造成的呢?
在运行JVM栈中，基本类型和引用的处理是一样的，都是传值，所以，如果是传引用的方法调用，也同时可以理解为“传引用值”的传值调用，即引用的处理跟基本类型是完全一样的。
但是当进入被调用方法时，被传递的这个引用的值，被程序解释(或者查找)到JVM堆中的对象，这个时候才对应到真正的对象。
如果此时进行修改，修改的是引用对应的对象，而不是引用本身，即：修改的是JVM堆中的数据。所以这个修改是可以保持的了。
从某种意义上来说对象都是由基本类型组成的。
可以把一个对象看作为一棵树，对象的属性如果还是对象，则还是一颗树(即非叶子节点)，基本类型则为树的叶子节点。程序参数传递时，被传递的值本身都是不能进行修改的，但是，如果这个值是一个非叶子节点(即一个对象引用)，则可以修改这个节点下面的所有内容。
其实，面向对象方式的程序与以前结构化的程序在执行上没有任何区别。
面向对象的引入，只是改变了我们对待问题的思考方式，而更接近于自然方式的思考。
当我们把对象拆开，其实对象的属性就是数据，存放在JVM堆中;而对象的行为(方法)，就是运行逻辑，放在JVM栈中。我们在编写对象的时候，其实即编写了数据结构，也编写的处理数据的逻辑。
关于数组的内存分配，对象初始化的内存分配等问题，由于篇幅问题，下次再搞个专题写吧。
连续几天几夜对着此文了。想吐的很，先到这里吧。
浏览 25343
分析得很细致，一遍没完全看明白，收藏下来，继续看同感
2.从数据共享的角度:.这块对整型的引用讲的很好。补充一点：整型在常量池里只能表示-128到127.超过这个范围的就不归常量池管了例如Integer a = 128;Integer b = 128;a==b& 返回的是false.如果：Integer a = 128;int b = 128;a == b 返回的是trueint a = 128;int b = 128;a == b 返回的也是true
查了下以前的帖子：
引用java虚拟机规范中说：Primitive values do not share state with other primitive values. A variable whose type is a primitive type always holds a primitive value of that type.
看一下实际的处理情况:
& int a=3;
& int b=3;
打开class文件，这2句就4个字节，内容是“06 3B 06 3C”
看对应的虚拟机指令，可以知道变量里实际存储的是什么:
Code:
& 0: iconst_3 //3
& 1: istore_1
& 2: iconst_3 //3
& 3: istore_2
第1个字节06 iconst_3是一个指令，让CPU把寄存器放上3的值
第2个字节3B istore_0也是一个指令，就是让CPU把寄存器的值放到第1个变量的内存中
第3个字节06 iconst_3是一个指令，让CPU把寄存器放上3的值
第4个字节3C istore_1也是一个指令，就是让CPU把寄存器的值放到第2个变量的内存中
（jvm没有“寄存器”的概念，用“Operand Stack 操作数栈”。）
int a = 3，int b =3是直接从指令获取数值，而没有进行栈中交换或进入常量池。
引用这里可以看到JAVA虚拟机的一个小技巧，它把一些对常用常量（比如0,1,2,3,4,5）的操作直接定义成了指令，而不是传统的操作指令后带操作数。
目的是减少指令长度。有心的人再用 int a = 6...试，根本就没有iconst_6的指令！
而是bipush 6，机器码10 06, 2个字节，10就是bipush， 06就是操作数6，就是传统的指令＋操作数。
那么大于6的数呢
引用
int e=32330;
对应指令：
11: sipush 32330
14: istore 5
这句,11-13,正好是3个字节的指令大小,一个字节是sipush指令,2个字节用来存储32330这个数.两次使用到这个数,都是把它直接存给变量的。
那么如果大于2个字节的数又如何？
引用
int f = 65535;
对应指令:
4: ldc #2; //int 65535
6: istore_3
对于65535,它是大于两个字节的,编译的时候把它放入常量池部分,而把取这个数的指令写为ldc#2,我感觉这样一个直观的好处是减少了指令代码的长度.尤其是多次使用到一个相同的数时.
大于2个字节的int数值，开始进入常量池。
那么int和Integer一样吗？
引用
Integer i = 3；
sun的编译器是这样处理的:
Integer i=Integer.valueOf(3);
而不是通过new来创建了,因为Integer类中静态的创建了-128~+127之间的对象,需要的数在这个范围之内时,直接返回,此范围之外的数才通过new来创建.
多谢多谢。& 我还真没注意在cpu中到底怎么处理这部分。
受教了。
java虚拟机规范中说：Primitive values do not share state with other primitive values. A variable whose type is a primitive type always holds a primitive value of that type.
看一下实际的处理情况:
& int a=3;
& int b=3;
打开class文件，这2句就4个字节，内容是“06 3B 06 3C”
看对应的虚拟机指令，可以知道变量里实际存储的是什么:
Code:
& 0: iconst_3 //3
& 1: istore_1
& 2: iconst_3 //3
& 3: istore_2
第1个字节06 iconst_3是一个指令，让CPU把寄存器放上3的值
第2个字节3B istore_0也是一个指令，就是让CPU把寄存器的值放到第1个变量的内存中
第3个字节06 iconst_3是一个指令，让CPU把寄存器放上3的值
第4个字节3C istore_1也是一个指令，就是让CPU把寄存器的值放到第2个变量的内存中
（jvm没有“寄存器”的概念，用“Operand Stack 操作数栈”。）
int a = 3，int b =3是直接从指令获取数值，而没有进行栈中交换或进入常量池。
引用这里可以看到JAVA虚拟机的一个小技巧，它把一些对常用常量（比如0,1,2,3,4,5）的操作直接定义成了指令，而不是传统的操作指令后带操作数。
目的是减少指令长度。有心的人再用 int a = 6...试，根本就没有iconst_6的指令！
而是bipush 6，机器码10 06, 2个字节，10就是bipush， 06就是操作数6，就是传统的指令＋操作数。
那么大于6的数呢
引用
int e=32330;
对应指令：
11: sipush 32330
14: istore 5
这句,11-13,正好是3个字节的指令大小,一个字节是sipush指令,2个字节用来存储32330这个数.两次使用到这个数,都是把它直接存给变量的。
那么如果大于2个字节的数又如何？
引用
int f = 65535;
对应指令:
4: ldc #2; //int 65535
6: istore_3
对于65535,它是大于两个字节的,编译的时候把它放入常量池部分,而把取这个数的指令写为ldc#2,我感觉这样一个直观的好处是减少了指令代码的长度.尤其是多次使用到一个相同的数时.
大于2个字节的int数值，开始进入常量池。
那么int和Integer一样吗？
引用
Integer i = 3；
sun的编译器是这样处理的:
Integer i=Integer.valueOf(3);
而不是通过new来创建了,因为Integer类中静态的创建了-128~+127之间的对象,需要的数在这个范围之内时,直接返回,此范围之外的数才通过new来创建.
写的不错，鼓励一下
多谢鼓励。
继续加油。
2.从数据共享的角度:.
这块对整型的引用讲的很好。
补充一点：整型在常量池里只能表示-128到127.超过这个范围的就不归常量池管了
例如
Integer a = 128;
Integer b = 128;
a==b& 返回的是false.
多谢指导，意思就是现在常量池整形只能存一个字节？
& 那么关于double等类型的是不是也有相应变化呢？
最近借不到《深入JVM》
还是再查查资料吧。
多些指导
& 上一页 1
浏览: 430707 次
来自: 长沙
说的很明白
initCacpcity和loadFactor为什么要stat ...
博主很用心啊，以下文章也挺好的jdk和jre的区别
我要向你学习！
。。。联盟招收小学弟吗- -