计算机内存的地址编码是以字节为单位的，即每字节内存都有个编号，8个二进制位为一个字节。
 
 
所以4G内存的地址范围是0x00000000~0xffffffff
 
那反过来问：为什么理论上32位系统最大只支持4G内存呢？
 
答:32位系统的“32”位是指cpu的地址总线是32根，这样就可以表示0~2^32-1一共2^32个地址，而地址编码是以字节为单位，所以内存最大2^32个字节，即4G

内存芯片型号是K4B4G1646E,不知道是多少容量，网上查找资料，有人说是512M，有人说26M。查看芯片手册发现是512M.BYTE.
 
 
  
 CONSUMER DRAM > DDR3 COMPONENT > K4B4G1646E
 
 
 
 
 
  
    Production Status
  
  

   Mass Production
  
  
    Density
  
  

   4Gb
  
 
 
 
 
  
    Organization
  
  

   256Mx16
  
  
    Speed
  
  

   K0, MA, NB
  
 
 
 
 
  
    Power
  
  

   C,Y
  
  
    Package
  
  

   96FBGA
  
 
 
 
 
  
    Application
  
  

   Smart TV, Digital Still/Video Cameras, Set Top Box, Gaming Console
  
 
 
 

 
 
上面的 256Mx16表示有256M个地址，数据宽度为16bit， 一共有4Gbit，也就是512MBYTE。
 
------------------------------------------------------------------------------------------------------
 

 
 

 
 

 

了解JVM内存结构的目的
 
在Java的开发过程中，因为有JVM自动内存管理机制，不再需要像在C、C++开发那样手动释放对象的内存空间，不容易出现内存泄漏和内存溢出的问题。但是，正是由于把内存管理的权利交给了JVM，一旦出现内存泄漏和内存溢出方面的问题，如果不了解JVM是如何使用内存的，不了解JVM的内存结构是什么样子的，就很难找到问题的根源，就更难以解决问题。
 
JVM内存结构简介
 
在JVM所管理的内存中，大致分为以下几个运行时数据区域：
 
 
程序计数器：当前线程所执行的字节码的行号指示器。
虚拟机栈：Java方法执行的内存模型，用于存储局部变量表、操作数栈、动态链接、方法出口等信息。
本地方法栈：本地方法执行的内存模型，和虚拟机栈非常相似，其区别是本地方法栈为JVM使用到的Native方法服务。
堆：用于存储对象实例，是垃圾收集器管理的主要区域。
方法区：用于存储已被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
 
其中，黄色区域的程序计数器、虚拟机栈和本地方法栈是线程私有的，红色区域的堆和方法区是线程共享的。下面我们逐一详细分析各个区域。
 
程序计数器
 
程序计数器（Program Counter Register）是一块较小的内存空间，它记录了当前线程所执行的字节码的行号。在JVM的概念模型里，字节码解释器工作时就是通过改变它的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都是依赖它来完成的。
 
通过线程轮流切换并分配处理器执行时间，实现了JVM的多线程操作。在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储，称这类内存区域为“线程私有”的内存。
 
如果线程正在执行的是一个Java方法，那么它记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是Natvie方法，它的值就为空（Undefined）。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
 
虚拟机栈
 
 
与程序计数器一样，Java虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，如上图每一个线程都有自己的虚拟机栈，它的生命周期与线程相同，当线程被创建时，虚拟机栈也同时被创建；当线程被销毁时，虚拟机栈也同时被销毁。
 
在线程内部，每个方法被执行的时候都会同时创建一个栈帧（Stack Frame），用于存储局部变量表、操作数栈、动态链接、方法出口等信息，如上图。每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
 
其中栈帧中的局部变量表存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型）和returnAddress类型（指向了一条字节码指令的地址）。
 
其中64位长度的long和double类型的数据会占用2个局部变量空间（Slot），其余的数据类型只占用1个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
 
在Java虚拟机规范中，对这个区域规定了两种异常状况：
 
如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常，让我们写一段代码，使其抛出该异常：
 
/**
 * VM Args: -Xss128k
 */
public class JVMStackSOF {
	private int stackLength = 1;

	public void stackLeak() {
		stackLength++;
		stackLeak();
	}

	public static void main(String[] args) {
		JVMStackSOF sof = new JVMStackSOF();
		try {
			sof.stackLeak();
		} catch (Throwable e) {
			System.out.println("Stack length:" + sof.stackLength);
			throw e;
		}
	}
}
 
在运行之前，设置JVM的参数为-Xss128k，运行结果如下：
 
Stack length:1002
Exception in thread "main" java.lang.StackOverflowError
	at OneMoreStudy.JVMStackSOF.stackLeak(JVMStackSOF.java:10)
	at OneMoreStudy.JVMStackSOF.stackLeak(JVMStackSOF.java:11)
	at OneMoreStudy.JVMStackSOF.stackLeak(JVMStackSOF.java:11)
......
 
栈的深度达到1002时，抛出了StackOverflowError异常。
 
如果虚拟机栈可以动态扩展，当扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常，还是让我们写一段代码，使其抛出该异常：
 
/**
 * VM Args: -Xss2M
 */
public class JVMStackOOM {
	private void dontStop() {
		while (true) {

		}
	}

	public void stackLeakByThread() {
		while (true) {
			Thread t = new Thread(new Runnable() {
				public void run() {
					dontStop();
				}
			});
			t.start();
		}
	}

	public static void main(String[] args) {
		JVMStackOOM oom = new JVMStackOOM();
		oom.stackLeakByThread();
	}
}
 
这段代码会创建出无限多的线程，因为Java的线程会映射系统的内核线程上，所以会造成CPU占用率100%，系统假死等现象，请谨慎运行。在运行之前，设置JVM的参数为-Xss2M，运行很长一段时间后结果如下：
 
Exception in thread "main" java.lang.OutMemoryError: unable to create new native thread
	at java.lang.Thread.start0(Native Method)
	at java.lang.Thread.start(Unknown Source)
	at OneMoreStudy.JVMStackOOM.stackLeakByThread(JVMStackOOM.java:18)
	at OneMoreStudy.JVMStackOOM.main(JVMStackOOM.java:24)
 
本地方法栈
 
本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的Native方法服务。
 
虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定，所以具体的虚拟机可以自由实现它。甚至有的虚拟机（比如Sun HotSpot虚拟机）直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。
 
堆
 
Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。它是被所有线程共享的一块内存区域，在虚拟机启动时创建。它就是用来存放对象实例的，几乎所有的对象实例都在这里分配内存。
 
堆是垃圾收集器管理的主要区域，如果从内存回收的角度看，由于现在收集器基本都是采用的分代收集算法，所以Java堆中还可以细分为：新生代和老年代；再细致一点的有Eden空间、From Survivor空间、To Survivor空间等。从内存分配的角度看，线程共享的堆中又可能划分出多个线程私有的分配缓存区（Thread Local Allocation Buffer，TLAB）。
 
根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。
 
如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常，再让我们写一段代码，使其抛出该异常：
 
/*
 * VM Args: -Xms20M -Xmx20M
 */
public class HeapOOM {
	static class OOMObject{
		
	}
	
	public static void main(String[] args){
		List<OOMObject> list = new ArrayList<OOMObject>();
		
		while(true){
			//把对象实例放入列表中，
			//使其一直被引用，不会被垃圾回收
			list.add(new OOMObject());
		}
	}
}
 
在运行之前，设置JVM的参数为-Xms20M -Xmx20M，运行结果如下：
 
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Unknown Source)
	at java.util.Arrays.copyOf(Unknown Source)
	at java.util.ArrayList.grow(Unknown Source)
	at java.util.ArrayList.ensureExplicitCapacity(Unknown Source)
	at java.util.ArrayList.ensureCapacityInternal(Unknown Source)
	at java.util.ArrayList.add(Unknown Source)
	at OneMoreStudy.HeapOOM.main(HeapOOM.java:18)

 
方法区
 
方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
 
对于习惯在HotSpot虚拟机上开发和部署程序的开发者来说，很多人愿意把方法区称为“永久代”（Permanent Generation），本质上两者并不等价，仅仅是因为HotSpot虚拟机的设计团队选择把GC分代收集扩展至方法区，或者说使用永久代来实现方法区而已。在JDK7的HotSpot中，已经把原本在永久代的字符串常量池移出，在JDK8的HotSpot中，已经没有永久代的存在了，而是采用了新的内存空间：元空间（Metaspace）。
 
JVM规范对这个区域的限制非常宽松，除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域是比较少出现的，但并不是数据进入了方法区就被一直存放。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是有必要的。
 
根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。再让我们写一段代码，尝试使其抛出该异常：
 
/*
 * VM Args: -XX:PermSize=2M -XX:MaxPermSize=2M
 */
public class RuntimeConstantPoolOOM {
	public static void main(String[] args) {
		List<String> list = new ArrayList<String>();
		for (int i = 0; i < 100000; i++) {
			System.out.println(i);
			//将i转化为字符串，
			//并且调用intern()，把字符串放在运行时常量池
			list.add(String.valueOf(i).intern());
		}
	}
}
 
在运行之前，设置JVM的参数为-XX:PermSize=2M -XX:MaxPermSize=2M。
 
在JDK6中运行抛出了老年代的OutOfMemoryError异常，结果如下：
 
......
35813
35814
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
        at java.lang.String.intern(Native Method)
        at OneMoreStudy.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java:12)
 
在JDK7中运行，循环全部完毕后，也没有抛出任何异常，结果如下：
 
......
99996
99997
99998
99999
 
同一段代码，在不同版本JDK中的运行结果为什么是不同的呢？这是因为：在JDK6中，字符串常量池还在永久代中，而在JDK7中，已经把原本在永久代的字符串常量池移出了。
 
再再让我们写一段代码，尝试使其抛出该异常：
 
/*
 * VM Args: -XX:PermSize=2M -XX:MaxPermSize=2M
 */
public class MethodAreaOOM {
	static class OOMObject {

	}
	
	public static void main(String[] args) {
		for (int i = 0; i < 300; i++) {
			System.out.println(i);
			createNewClass();
		}
	}

	private static void createNewClass() {
		//这里使用了CGLIB，动态创建类，载入方法区
		Enhancer enhancer = new Enhancer();
		enhancer.setSuperclass(OOMObject.class);
		enhancer.setUseCache(false);
		enhancer.setCallback(new MethodInterceptor() {

			@Override
			public Object intercept(Object obj, Method method,
					Object[] args, MethodProxy proxy) throws Throwable {
				return proxy.invokeSuper(obj, args);
			}
		});
		enhancer.create();
	}
}
 
在运行之前，设置JVM的参数为-XX:PermSize=2M -XX:MaxPermSize=2M。
 
在JDK6中运行抛出了老年代的OutOfMemoryError异常，，结果如下：
 
......
Caused by: java.lang.OutOfMemoryError: PermGen space
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(Unknown Source)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        ... 12 more
 
在JDK7中运行也抛出了OutOfMemoryError异常，结果如下：
 
Exception in thread "main"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main"
 
在JDK8中运行，循环全部完毕后，也没有抛出任何异常，结果如下：
 
......
298
299
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=2M; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=2M; support was removed in 8.0
 
同一段代码，在不同版本JDK中的运行结果为什么是不同的呢？这是因为：在JDK6和JDK7中，永久代仍然存在，而在JDK8中，已经没有永久代的存在了，而是采用了新的内存空间：元空间，并且JVM参数PermSize和MaxPermSize也被移出了。
 
总结
 
在JVM所管理的内存中，大致分为：程序计数器、虚拟机栈、本地方法栈、堆和方法区。程序计数器是当前线程所执行的字节码的行号指示器。虚拟机栈是Java方法执行的内存模型，用于存储局部变量表、操作数栈、动态链接、方法出口等信息。本地方法栈是本地方法执行的内存模型，和虚拟机栈非常相似，其区别是本地方法栈为JVM使用到的Native方法服务。堆是用于存储对象实例的，是垃圾收集器管理的主要区域。方法区用于存储已被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

    在python中，万物皆对象，常见的整数、浮点数、字符串、元祖、列表等类型，以及各种class、class instance等等都是对象。这些对象在python解释器内部的地址是怎样的呢？这里我们只简单看下python对象内存地址的相关基础知识，以及编码过程中一些注意事项，关于python解释器的内存管理机制，涉及到解释器内核的内存池原理，这里不做深入探讨，有兴趣的朋友可以去阅读解释器源代码。
 
0x01 不可变对象
 
    不可变对象是指对象的内存值不能被改变。Python中变量以引用的方式指向对象，如果变量引用了不可变对象，当改变该变量时，由于其所指的对象的值不能被改变，相当于把原来的值复制一份后再改变，这会开辟一个新的地址，变量再指向这个新的地址，即变量引用了新的对象。
 
    数值类型（整数和浮点）、字符串str、元组tuple都是不可变类型。比如a=1，b=[1]，c={'a':1}，id(a)、id(b[0])、id(1)、id(c['a'])将输出一样的值，因为1是不可变对象，其在内存中是不可改变的。
 
0x02 可变对象
 
    可变对象是指对象的内存值可以被改变，变量（准确的说是引用）改变后，实际上是其所指的值直接发生改变，并没有发生复制行为，也没有开辟新的内存地址，通俗点说就是原地改变。列表list、字典dict、集合set是可变类型。
 
0x03 对象的内存地址
 
    可以使用内置函数id()查看python对象的内存地址。下面是一些注意事项：
 
    (1) python中所有数字、字符串、list等值，创建时会分配内存空间，变量通过引用的方式使用它们。比如a=1和b=1，id(a)和id(b)的输出一样，表示a和b都指向相同的内存地址，即引用了同一个不可变对象；但是a=[1]和b=[1]，id(a)和id(b)将输出不一样的值，a和b指向的是不同的内存地址，即引用了不同的可变对象，说明各可变对象是相互独立的，在内存中有独立的内存地址；
 
    (2) 可用 is 判断两个对象的id（即内存地址）是否一样，用 == 判断两个对象的值是否一样。None值也有内存地址；
 
    (3) list、set对象有各自的独立内存空间，他们的各元素以引用的方式指向可变、不可变对象；
 
    (4) 函数形参的默认值，在内存中会开辟独立的内存空间。比如测试代码中test函数的param参数，其默认值是空list，如果调用时未传参，则param指向内存中预先分配好的地址，该地址存储的是list类型的值；当调用时传参为a，则param引用了a指向的内存空间；
 
    (5) python使用引用计数和垃圾回收来释放内存对象，每个内存对象都维护了一个引用计数，包括各种数字、字符串、list、set等类型值，以及类实例对象等等，当这些对象的引用计数为 0 时，会被解释器回收内存。每次对对象进行引用操作，都会导致其引用计数加1， 如下面测试代码中的整数1，列表a、b、c、d、n都引用了整数1，以及test函数中的append操作，都会导致数字1的引用计数加1；
 
    (6) copy和deepcopy方法都创建了新的内存对象，如测试代码中的b和c都是新的变量，其各个元素可能是指向同一个内存空间。赋值操作是指向同一个内存块，同时增加引用计数。copy是浅拷贝，deepcopy是深拷贝，特别对于可变对象，copy是以引用的方式指向同一个可变对象，而deepcopy会开辟新的内存地址，也就是创建了新的可变对象。
 
0x04 测试代码
 
# -*- coding: utf8 -*-
import copy
import sys

a = [1, 2, [3, 4]]
b = copy.copy(a)
c = copy.deepcopy(a)
d = a

print 'address of a:', id(a)
print 'address of b:', id(b)
print 'address of c:', id(c)
print 'address of d:', id(d)
print 'address of 1:', id(1)
print 'address of element 0 in a:', id(a[0])
print 'address of element 0 in b:', id(b[0])
print 'address of element 0 in c:', id(c[0])
print 'a=', a
print 'b=', b
print 'c=', c
print 'd=', d

a[0] = 99
print 'a=', a
print 'b=', b
print 'c=', c
print 'd=', d

print 'address of element 0 in a:', id(a[0])
print 'address of element 0 in b:', id(b[0])
print 'address of element 0 in c:', id(c[0])

print 'address of element 2 in a:', id(a[2])
print 'address of element 2 in b:', id(b[2])
print 'address of element 2 in c:', id(c[2])

a[2].append(5)
print 'a=', a
print 'b=', b
print 'c=', c
print 'd=', d

def test(param=[]):
    print 'address of param:', id(param)
    param.append(1)
    print 'reference count of 1:', sys.getrefcount(1)
    return param

print test(a)
print test()
print test()
print 'a=', a
print 'b=', b
print 'c=', c
print 'd=', d

print 'reference count of 1:', sys.getrefcount(1)
n = 1
print 'reference count of 1:', sys.getrefcount(1)
del n
print 'reference count of 1:', sys.getrefcount(1)

 
0x06 运行结果
 
 
 
address of a: 54681224
 address of b: 54716296
 address of c: 54692104
 address of d: 54681224
 address of 1: 48258856
 address of element 0 in a: 48258856
 address of element 0 in b: 48258856
 address of element 0 in c: 48258856
 a= [1, 2, [3, 4]]
 b= [1, 2, [3, 4]]
 c= [1, 2, [3, 4]]
 d= [1, 2, [3, 4]]
 a= [99, 2, [3, 4]]
 b= [1, 2, [3, 4]]
 c= [1, 2, [3, 4]]
 d= [99, 2, [3, 4]]
 address of element 0 in a: 48260488
 address of element 0 in b: 48258856
 address of element 0 in c: 48258856
 address of element 2 in a: 54692232
 address of element 2 in b: 54692232
 address of element 2 in c: 54716360
 a= [99, 2, [3, 4, 5]]
 b= [1, 2, [3, 4, 5]]
 c= [1, 2, [3, 4]]
 d= [99, 2, [3, 4, 5]]
 address of param: 54681224
 reference count of 1: 161
 [99, 2, [3, 4, 5], 1]
 address of param: 54716424
 reference count of 1: 162
 [1]
 address of param: 54716424
 reference count of 1: 163
 [1, 1]
 a= [99, 2, [3, 4, 5], 1]
 b= [1, 2, [3, 4, 5]]
 c= [1, 2, [3, 4]]
 d= [99, 2, [3, 4, 5], 1]
 reference count of 1: 163
 reference count of 1: 164
 reference count of 1: 163