1 Java技术与Java虚拟机
说起Java，人们首先想到的是Java编程语言，然而事实上，Java是一种技术，它由四方面组成: Java编程语言、Java类文件格式、Java虚拟机和Java应用程序接口(Java API)。它们的关系如下图所示：
图1 Java四个方面的关系
运行期环境代表着Java平台，开发人员编写Java代码(.java文件)，然后将之编译成字节码(.class文件)。最后字节码被装入内存， 一旦字节码进入虚拟机，它就会被解释器解释执行，或者是被即时代码发生器有选择的转换成机器码执行。从上图也可以看出Java平台由Java虚拟机和 Java应用程序接口搭建，Java语言则是进入这个平台的通道，用Java语言编写并编译的程序可以运行在这个平台上。这个平台的结构如下图所示：
当JVM运行Java程序的时候，它会加载对应的class文件，并提取class文件中的信息存放在JVM开辟出来的方法区 内存中。那么这个class文件里面到底有些什么内容呢？
一、class文件内容概述
class文件是由8bits的字节流组成，全部字节构成了15个有意义的项目。这些项目之间没有任何无意义的字节，因此class文件非常紧凑。占据多字节空间的项目按照高位在前的顺序存放。下面我们详细讨论这些项目：
★ magic(魔数) 每个class文件的前4个字节称为魔数，值为0xCAFEBABE。作用在于轻松的辨别class文件与非class文件。
★ minor_version、major_version(次、主版本号) 各占2个字节。随着Java技术的发展，class文件的格式会发生变化。版本号的作用在于使得虚拟机能够认识当前加载class的文件格式。从而准确的提取class文件信息。
★ constant_pool_count 、constance_pool（常量池） 从这里开始的字节组成了常量池 。 存储了诸如符号常量、final常量值、基本数据类型的字面值等内容。JVM会将每一个常量构成一个常量表，每个常量表都有自己的入口地址。而实际上在 JVM会将这些常量表存储在方法区中一块连续的内存空间中，因此class文件会根据常量表在常量池中的位置对其进行索引。比如常量池中的第一个常量表的 索引值就是1，第二个就是2。有的时候常量表A需要常量表B的内容，则在常量表A中会存储常量表B的索引值x。而constant_pool_count 就记录了有多少个常量表，或则所有多少个索引值。实际上，常量池中没有索引值为0的常量表，但这缺失的索引值也被记录在 constant_pool_count中，因此 constant_pool_count等于常量表的数量加1。关于常量池的具体内容，我们会在下面详细讲述，并用一个例子来显示整个class文件的内容。
值类型：是存储在内存中的堆栈（以后简称栈 ou shit 很久以前老是把堆栈和堆等同~英文不就很好区分吗！ stack heap！！~~我擦~）。
引用类型：变量在栈中仅仅是存储引用类型变量的地址，而其本身则存储在堆中。
==操作比较的是两个变量的值是否相等，对于引用型变量表示的是两个变量在堆中存储的地址是否相同，即栈中的内容是否相同。
equals操作表示的两个变量是否是对同一个对象的引用，即堆中的内容是否相同。
==比较的是2个对象的地址，而equals比较的是2个对象的内容。
显然，当equals为true时，==不一定为true；
一、String中的equals和==
1、
public class TestString {
public static void main(String[] args) {
String s1 = “Monday”;
String s2 = “Monday”;
}
}
String是不可改变，定长；
StringBuffer是不定长，可改变，通过分配更大的内存实现，StringBuffer是线程安全的可变字符序列。可将字符串缓冲区安全地用于多个线程。可以在必要时对这些方法进行同步。
StringBuilder是单个线程使用的StringBuffer等价类，一个可变的字符序列。此类提供一个与 StringBuffer 兼容的 API，但不保证同步。该类被设计用作 StringBuffer 的一个简易替换，用在字符串缓冲区被单个线程使用的时候（这种情况很普遍）。如果可能，建议优先采用该类，因为在大多数实现中，它比 StringBuffer 要快。
在 StringBuilder 上的主要操作是 append 和 insert 方法， append 方法始终将这些字符添加到生成器的末端；而 insert 方法则在指定的点添加字符。将 StringBuilder 的实例用于多个线程是不安全的。如果需要这样的同步，则建议使用 StringBuffer。
注意：本来以为StringBuilder和StringBuffer的equals方法是可以比较两个字符串的内容是否相等，今天才发现不是这么回事。这两个类都直接继承自Object，并且没有重写equals方法。
Hashtable和HashMap类有三个重要的不同之处。第一个不同主要是历史原因。Hashtable是基于陈旧的Dictionary类的，HashMap是Java 1.2引进的Map接口的一个实现。
也 许最重要的不同是Hashtable的方法是同步的，而HashMap的方法不是。这就意味着，虽然你可以不用采取任何特殊的行为就可以在一个多线程的应 用程序中用一个Hashtable，但你必须同样地为一个HashMap提供外同步。一个方便的方法就是利用Collections类的静态的 synchronizedMap()方法，它创建一个线程安全的Map对象，并把它作为一个封装的对象来返回。这个对象的方法可以让你同步访问潜在的 HashMap。这么做的结果就是当你不需要同步时，你不能切断Hashtable中的同步（比如在一个单线程的应用程序中），而且同步增加了很多处理费 用。
第三点不同是，只有HashMap可以让你将空值作为一个表的条目的key或value。HashMap中只有一条记录可以是一 个空的key，但任意数量的条目可以是空的value。这就是说，如果在表中没有发现搜索键，或者如果发现了搜索键，但它是一个空的值，那么get()将 返回null。如果有必要，用containKey()方法来区别这两种情况。
一些资料建议，当需要同步时，用Hashtable， 反之用HashMap。但是，因为在需要时，HashMap可以被同步，HashMap的功能比Hashtable的功能更多，而且它不是基于一个陈旧的 类的，所以有人认为，在各种情况下，HashMap都优先于Hashtable。
关于Properties
深入理解JMM more understanding about jmm java memory model(本站开始做英文SEO了)
深入理解JMM的重点
JMM具体规定要JLS的 “Thread and lock”一章中,可以说这是一章非常晦涩的一个规范,要想完全把
它理解清楚,一般的辛苦是不行的.那是要”相当的~~~”的辛苦.而要把它向别人再解释清楚,那简直就
是恶梦.
作者自知无力能全面清楚地向大家说明这一章的内容,但以作者的经验,主要从以下两个方面去理解
可以改快地抓住本质.而不至于陷入”Thread and lock”的泥潭.
一.理解主存储区和线程工作存储区.
二.理解同步的两个功能.
首先要明白的问题:
1.多个线程共有的字段应该用synchronized或volatile来保护.
2.synchronized负责线程间的互斥.即同一时候只有一个线程可以执行synchronized中的代码.
3.volatile负责线程中的变量与主存储区同步.但不负责每个线程之间的同步.
[Main Memory]与[Working Memory]
Main Memory是实例所在的存储区,所有实例和实例的字段都在此区域,为所有线程所共有.
Working Memory是绺个线程独自所拥有的存储区.其中有Main Memory中部分COPY.
Java™ 语言包含两种内在的同步机制：同步块（或方法）和 volatile 变量。这两种机制的提出都是为了实现代码线程的安全性。其中 Volatile 变量的同步性较差（但有时它更简单并且开销更低），而且其使用也更容易出错。在这期的 Java 理论与实践中，Brian Goetz 将介绍几种正确使用 volatile 变量的模式，并针对其适用性限制提出一些建议。
Java 语言中的 volatile 变量可以被看作是一种 “程度较轻的 synchronized”；与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是 synchronized 的一部分。本文介绍了几种有效使用 volatile 变量的模式，并强调了几种不适合使用 volatile 变量的情形。
锁提供了两种主要特性：互斥（mutual exclusion） 和可见性（visibility）。
互斥 即一次只允许一个线程持有某个特定的锁，因此可使用该特性实现对共享数据的协调访问协议，这样，一次就只有一个线程能够使用该共享数据。
可见性要更加复杂 一些，它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的【就是修改必须同步到主存的意思？】 —— 如果没有同步机制提供的这种可见性保证，线程看到的共享变量可能是修改前的值或不一致的值，这将引发许多严重问题。
这是一个实战中非常重要但是容易被忽视的概念，说它重要，是因为它比数据库重要；说它容易被忽视也是同样的原因，它经常被数据库概念替代。
如果你经验和经历中没有状态这个概念，极端地说：可能你的Java系统经验还未积累到一定程度，状态是每个Java程序员深入Java系统后必然碰到的问题。
本文我想试图表达的是：状态分两种：活动的状态对象和持久化的状态。而数据库中的数据只是状态的一种持久化结果，而Java系统 运行时，我们更多的可能是和一种活动的状态打交道，这种活动的状态存在内存中，而不是持久化到硬盘上，当然，需要时你可以通过数据库/文件持久化到硬盘上。
但是，如果你以数据库数据替代状态，那么就可能导致数据库的频繁访问，而且 你的系统会变成一个非对象化的、紧耦合、到处是分散数据块的糟糕系统。这样的系统并不比传统的两层结构好到哪里！也不会比Jsp里嵌入Java代码伪三层系统高明到什么地方。
什么是状态？
只要有对象就可能有状态，任何一个对象活动时，都有自己的状态属性，类的 字段属性极有可能成为状态，我们现在经常使用的Domain model其实就是一种 包含状态的对象，如果你对状态没有深入掌握，就不可能真正掌握对象系统特点，或者是Domain Model的执行情况。
对于初学者，经常会疑问：我是将数据放在HttpSession中还是Request中，这里 其实已经开始接触状态，一旦你接触状态，你就要开始小心，因为你可能会将内存泄漏的恶魔导引进来。
内存泄漏的恶魔爆发时刻取决于你状态的生存周期和系统并发访问量。
目前网络上关于对象序列化的文章不少，但是我发现详细叙述用法和原理的文章太少。本人把自己经过经验总结和实际运用中的体会.
序列化的过程就是对象写入字节流和从字节流中读取对象。将对象状态转换成字节流之后，可以用java.io包中的各种字节流类将其保存到文件中，管道到另 一线程中或通过网络连接将对象数据发送到另一主机。对象序列化功能非常简单、强大，在RMI、Socket、JMS、EJB都有应用。对象序列化问题在网 络编程中并不是最激动人心的课题，但却相当重要，具有许多实用意义。
1.对象序列化可以实现分布式对象。主要应用例如：RMI要利用对象序列化运行远程主机上的服务，就像在本地机上运行对象时一样。
2.java对象序列化不仅保留一个对象的数据，而且递归保存对象引用的每个对象的数据。可以将整个对象层次写入字节流中，可以保存在文件中或在网络连接 上传递。利用对象序列化可以进行对象的“深复制”，即复制对象本身及引用的对象本身。序列化一个对象可能得到整个对象序列。
从上面的叙述中，我们知道了对象序列化是java编程中的必备武器，那么让我们从基础开始，好好学习一下它的机制和用法。
java序列化比较简单，通常不需要编写保存和恢复对象状态的定制代码。实现java.io.Serializable接口的类对象可以转换成字节流或从 字节流恢复，不需要在类中增加任何代码。只有极少数情况下才需要定制代码保存或恢复对象状态。这里要注意：不是每个类都可序列化，有些类是不能序列化的， 例如涉及线程的类与特定JVM有非常复杂的关系。
序列化机制：
1.反射机制概述
Reflection是Java 程序开发语言的特征之一，它允许运行中的 Java 程序对自身进行检查，或者说”自审”，并能直接操作程序的内部属性。例如，使用它能获得 Java 类中各成员的名称并显示出来。这种动态获取类的信息以及动态调用对象的方法的功能来自于Java 语言的反射（Reflection）机制。
Java 反射机制主要提供了以下功能：
在运行时判断任意一个对象所属的类。
在运行时构造任意一个类的对象。
在运行时判断任意一个类所具有的成员变量和方法。
在运行时调用任意一个对象的方法。
在JDK中，主要由以下类来实现Java反射机制，这些类都位于java.lang.reflect包中：
Class类：代表一个类。
Field 类：代表类的成员变量（成员变量也称为类的属性）。
Method类：代表类的方法。
Constructor 类：代表类的构造方法。
Array类：提供了动态创建数组，以及访问数组的元素的静态方法。[1]
