serialVersionUID的作用

详见这篇文档  http://lenjey.iteye.com/blog/513736

简单来说就是，在序列化对象时，编译器会自动给对象生成一个serialVersionUID，之后任意改动这个对象都会与编译器生成的UID不匹配。如果我们显示指定了serialVersionUID，那么对象序列化之后，也可以修改这个对象。

serialVersionUID生成

我们可以任意指定serialVersionUID，如

private static final long serialVersionUID = 1L;

但最好还是使用让系统按照摘要算法生成一个指纹数字。eclipse是可以自动生成的，IDEA需要简单配置一下。

IntelliJ IDEA->Preferences->Inspections界面下

Serializable class without serialVersionUID后打钩，注意上面的Profile选为Default。

（继承了Serializable的类没有serialVersionUID就会Warning）

之后光标在继承了Serializable的类名上按 ALT+ENTER键，就会出现 Add serialVersionUID field 选项，生成的UID如下

private static final long serialVersionUID = 6496849704004740865L;

1.Properties类与Properties配置文件

Properties类继承自Hashtable类并且实现了Map接口，也是使用一种键值对的形式来保存属性集。不过Properties有特殊的地方，就是它的键和值都是字符串类型。

2.Properties中的主要方法

(1)load(InputStream inStream)

 　　这个方法可以从.properties属性文件对应的文件输入流中，加载属性列表到Properties类对象。如下面的代码：

Properties pro = new Properties();
FileInputStream in = new FileInputStream("a.properties");
pro.load(in);
in.close();

(2)store(OutputStream out, String comments)

这个方法将Properties类对象的属性列表保存到输出流中。如下面的代码：

FileOutputStream oFile = new FileOutputStream(file, "a.properties");
pro.store(oFile, "Comment");
oFile.close();

如果comments不为空，保存后的属性文件第一行会是#comments,表示注释信息；如果为空则没有注释信息。

注释信息后面是属性文件的当前保存时间信息。

(3)getProperty/setProperty

这两个方法是分别是获取和设置属性信息。

3.代码实例

属性文件a.properties如下：

name=root
pass=liu
key=value

读取a.properties属性列表，与生成属性文件b.properties。代码如下：

import java.io.BufferedInputStream;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.InputStream; 
import java.util.Iterator;
import java.util.Properties; 

public class PropertyTest {
    public static void main(String[] args) { 
        Properties prop = new Properties();     
        try{
            //读取属性文件a.properties
            InputStream in = new BufferedInputStream (new FileInputStream("a.properties"));
            prop.load(in);     ///加载属性列表
            Iterator<String> it=prop.stringPropertyNames().iterator();
            while(it.hasNext()){
                String key=it.next();
                System.out.println(key+":"+prop.getProperty(key));
            }
            in.close();
            
            ///保存属性到b.properties文件
            FileOutputStream oFile = new FileOutputStream("b.properties", true);//true表示追加打开
            prop.setProperty("phone", "10086");
            prop.store(oFile, "The New properties file");
            oFile.close();
        }
        catch(Exception e){
            System.out.println(e);
        }
    } 
}

参考链接

---

Java 读写Properties配置文件

JAVA中的内存泄漏

JAVA编程中的内存泄漏，从泄漏的内存位置角度可以分为两种：JVM中Java Heap的内存泄漏；JVM内存中native memory的内存泄漏。

Java Heap的内存泄漏

Java对象存储在JVM进程空间中的Java Heap中，Java Heap可以在JVM运行过程中动态变化。如果Java对象越来越多，占据Java Heap的空间也越来越大，JVM会在运行时扩充Java Heap的容量。如果Java Heap容量扩充到上限，并且在GC后仍然没有足够空间分配新的Java对象，便会抛出out of memory异常，导致JVM进程崩溃。

Java Heap中out of memory异常的出现有两种原因——①程序过于庞大，致使过多Java对象的同时存在；②程序编写的错误导致Java Heap内存泄漏。

多种原因可能导致Java Heap内存泄漏。JNI编程错误也可能导致Java Heap的内存泄漏。

JVM中native memory的内存泄漏

从操作系统角度看，JVM在运行时和其它进程没有本质区别。在系统级别上，它们具有同样的调度机制，同样的内存分配方式，同样的内存格局。

JVM进程空间中，Java Heap以外的内存空间称为JVM的native memory。进程的很多资源都是存储在JVM的native memory中，例如载入的代码映像，线程的堆栈，线程的管理控制块，JVM的静态数据、全局数据等等。也包括JNI程序中native code分配到的资源。

在JVM运行中，多数进程资源从native memory中动态分配。当越来越多的资源在native memory中分配，占据越来越多native memory空间并且达到native memory上限时，JVM会抛出异常，使JVM进程异常退出。而此时Java Heap往往还没有达到上限。

多种原因可能导致JVM的native memory内存泄漏。例如JVM在运行中过多的线程被创建，并且在同时运行。JVM为线程分配的资源就可能耗尽native memory的容量。

JNI编程错误也可能导致native memory的内存泄漏。对这个话题的讨论是本文的重点。

---

JNI编程中明显的内存泄漏

JNI编程实现了native code和Java程序的交互，因此JNI代码编程既遵循 native code编程语言的编程规则，同时也遵守JNI编程的文档规范。在内存管理方面，native code编程语言本身的内存管理机制依然要遵循，同时也要考虑JNI编程的内存管理。

本章简单概括JNI编程中显而易见的内存泄漏。从native code编程语言自身的内存管理，和JNI规范附加的内存管理两方面进行阐述。

Native Code本身的内存泄漏

JNI编程首先是一门具体的编程语言，或者C语言，或者C++，或者汇编，或者其它native的编程语言。每门编程语言环境都实现了自身的内存管理机制。因此，JNI程序开发者要遵循native语言本身的内存管理机制，避免造成内存泄漏。以C语言为例，当用malloc()在进程堆中动态分配内存时，JNI程序在使用完后，应当调用free()将内存释放。总之，所有在native语言编程中应当注意的内存泄漏规则，在JNI编程中依然适应。

Native语言本身引入的内存泄漏会造成native memory的内存，严重情况下会造成native memory的out of memory。

Global Reference引入的内存泄漏

JNI编程还要同时遵循JNI的规范标准，JVM附加了JNI编程特有的内存管理机制。

JNI中的Local Reference只在native method执行时存在，当native method执行完后自动失效。这种自动失效，使得对Local Reference的使用相对简单，native method执行完后，它们所引用的Java对象的reference count会相应减1。不会造成Java Heap中Java对象的内存泄漏。

而Global Reference对Java对象的引用一直有效，因此它们引用的Java对象会一直存在Java Heap中。程序员在使用Global Reference时，需要仔细维护对Global Reference的使用。如果一定要使用Global Reference，务必确保在不用的时候删除。就像在C语言中，调用malloc()动态分配一块内存之后，调用free()释放一样。否则，Global Reference引用的Java对象将永远停留在Java Heap中，造成Java Heap的内存泄漏。

---

JNI编程中潜在的内存泄漏——对LocalReference的深入理解

Local Reference在native method执行完成后，会自动被释放，似乎不会造成任何的内存泄漏。但这是错误的。对Local Reference的理解不够，会造成潜在的内存泄漏。

本章重点阐述Local Reference使用不当可能引发的内存泄漏。引入两个错误实例，也是JNI程序员容易忽视的错误；在此基础上介绍Local Reference表，对比native method中的局部变量和JNI Local Reference的不同，使读者深入理解JNI Local Reference的实质；最后为JNI程序员提出应该如何正确合理使用JNI Local Reference，以避免内存泄漏。

错误实例 1

在某些情况下，我们可能需要在native method里面创建大量的JNI Local Reference。这样可能导致 native memory的内存泄漏，如果在native method返回之前native memory已经被用光，就会导致native memory的out of memory。

在代码清单 1 里，我们循环执行count次，JNI functionNewStringUTF()在每次循环中从Java Heap中创建一个String对象，str是Java Heap传给JNI native method的Local Reference，每次循环中新创建的String对象覆盖上次循环中str的内容。str似乎一直在引用到一个String对象。整个运行过程中，我们看似只创建一个Local Reference。

执行代码清单1的程序，第一部分为Java代码，nativeMethod(int i)中，输入参数设定循环的次数。第二部分为JNI代码，用C语言实现了nativeMethod(int i)。

清单 1. Local Reference引发内存泄漏

 Java 代码部分
 class TestLocalReference { 
 private native void nativeMethod(int i); 
 public static void main(String args[]) { 
         TestLocalReference c = new TestLocalReference(); 
         //call the jni native method 
         c.nativeMethod(1000000); 
 }  
 static { 
 //load the jni library 
 System.loadLibrary("StaticMethodCall"); 
 } 
 } 

 JNI代码，nativeMethod(int i)的C语言实现
 #include<stdio.h> 
 #include<jni.h> 
 #include"TestLocalReference.h"
 JNIEXPORT void JNICALL Java_TestLocalReference_nativeMethod 
 (JNIEnv * env, jobject obj, jint count) 
 { 
 jint i = 0; 
 jstring str; 

 for(; i<count; i++) 
         str = (*env)->NewStringUTF(env, "0"); 
 } 
运行结果
 JVMCI161: FATAL ERROR in native method: Out of memory when expanding 
 local ref table beyond capacity 
 at TestLocalReference.nativeMethod(Native Method) 
 at TestLocalReference.main(TestLocalReference.java:9)

运行结果证明，JVM运行异常终止，原因是创建了过多的Local Reference，从而导致out of memory。实际上，nativeMethod在运行中创建了越来越多的JNI Local Reference，而不是看似的始终只有一个。过多的Local Reference，导致了JNI内部的JNI Local Reference表内存溢出。

错误实例 2

实例 2 是实例 1 的变种，Java代码未作修改，但是nativeMethod(int i)的C语言实现稍作修改。在JNI的native method中实现的utility函数中创建Java的String对象。utility函数只建立一个String对象，返回给调用函数，但是utility函数对调用者的使用情况是未知的，每个函数都可能调用它，并且同一函数可能调用它多次。在实例 2 中，nativeMethod在循环中调用count次，utility函数在创建一个String对象后即返回，并且会有一个退栈过程，似乎所创建的Local Reference会在退栈时被删除掉，所以应该不会有很多Local Reference被创建。实际运行结果并非如此。

清单 2. Local Reference引发内存泄漏

 Java 代码部分参考实例 1，未做任何修改。

 JNI 代码，nativeMethod(int i) 的 C 语言实现
 #include<stdio.h> 
 #include<jni.h> 
 #include"TestLocalReference.h"
 jstring CreateStringUTF(JNIEnv * env) 
 { 
 return (*env)->NewStringUTF(env, "0"); 
 } 
 JNIEXPORT void JNICALL Java_TestLocalReference_nativeMethod 
 (JNIEnv * env, jobject obj, jint count) 
 { 
 jint i = 0; 
 for(; i<count; i++) 
 { 
         str = CreateStringUTF(env); 
 } 
 } 
运行结果
 JVMCI161: FATAL ERROR in native method: Out of memory when expanding local ref 
 table beyond  capacity 
 at TestLocalReference.nativeMethod(Native Method) 
 at TestLocalReference.main(TestLocalReference.java:9)

运行结果证明，实例 2 的结果与实例 1 的完全相同。过多的Local Reference被创建，仍然导致了JNI内部的 JNI Local Reference表内存溢出。实际上，在utility函数CreateStringUTF(JNIEnv * env)

执行完成后的退栈过程中，创建的Local Reference并没有像native code中的局部变量那样被删除，而是继续在Local Reference表中存在，并且有效。Local Reference 和局部变量有着本质的区别。

Local Reference深层解析

Java JNI的文档规范只描述了JNI Local Reference是什么（存在的目的），以及应该怎么使用Local Reference（开放的接口规范）。但是对Java虚拟机中JNI Local Reference的实现并没有约束，不同的Java虚拟机有不同的实现机制。这样的好处是，不依赖于具体的JVM实现，有好的可移植性；并且开发简单，规定了“应该怎么做、怎么用”。但是弊端是初级开发者往往看不到本质，“不知道为什么这样做”。对Local Reference没有深层的理解，就会在编程过程中无意识的犯错。

Local Reference和Local Reference表

理解Local Reference表的存在是理解JNI Local Reference的关键。

JNI Local Reference的生命期是在native method的执行期（从Java程序切换到native code环境时开始创建，或者在native method执行时调用JNI function创建），在 native method执行完毕切换回Java程序时，所有JNI Local Reference被删除，生命期结束（调用JNI function可以提前结束其生命期）。

实际上，每当线程从Java环境切换到native code上下文时（J2N），JVM会分配一块内存，创建一个Local Reference表，这个表用来存放本次native method执行中创建的所有的Local Reference。每当在native code中引用到一个Java对象时，JVM就会在这个表中创建一个Local Reference。比如，实例 1 中我们调用NewStringUTF()在Java Heap中创建一个String对象后，在Local Reference表中就会相应新增一个Local Reference。

图 1. Local Reference表、Local Reference和Java对象的关系

图 1 中：

⑴运行native method的线程的堆栈记录着Local Reference表的内存位置（指针 p）。

⑵ Local Reference表中存放JNI Local Reference，实现Local Reference到Java对象的映射。

⑶ native method代码间接访问Java对象（java obj1，java obj2）。通过指针p定位相应的Local Reference的位置，然后通过相应的Local Reference映射到Java对象。

⑷ 当native method引用一个Java对象时，会在Local Reference表中创建一个新Local Reference。在Local Reference结构中写入内容，实现Local Reference到Java对象的映射。

⑸native method调用DeleteLocalRef()释放某个JNI Local Reference时，首先通过指针p定位相应的Local Reference在Local Ref表中的位置，然后从Local Ref表中删除该Local Reference，也就取消了对相应Java对象的引用（Ref count减1）。

⑹当越来越多的Local Reference被创建，这些Local Reference会在Local Ref表中占据越来越多内存。当Local Reference太多以至于Local Ref表的空间被用光，JVM会抛出异常，从而导致JVM的崩溃。

Local Ref不是native code的局部变量

很多人会误将JNI中的Local Reference理解为Native Code的局部变量。这是错误的。

Native Code的局部变量和Local Reference是完全不同的，区别可以总结为：

⑴局部变量存储在线程堆栈中，而Local Reference存储在Local Ref表中。

⑵局部变量在函数退栈后被删除，而Local Reference在调用DeleteLocalRef()后才会从Local Ref表中删除，并且失效，或者在整个Native Method执行结束后被删除。

⑶ 可以在代码中直接访问局部变量，而Local Reference的内容无法在代码中直接访问，必须通过JNI function间接访问。JNI function实现了对Local Reference的间接访问，JNI function的内部实现依赖于具体JVM。

代码清单 1 中 str = (*env)->NewStringUTF(env, "0");

str是jstring类型的局部变量。Local Ref表中会新创建一个Local Reference，引用到NewStringUTF(env, "0")在Java Heap中新建的String对象。如图 2 所示：

图 2. str 间接引用 string 对象

图 2 中，str 是局部变量，在 native method 堆栈中。Local Ref3 是新创建的 Local Reference，在 Local Ref 表中，引用新创建的 String 对象。JNI 通过 str 和指针 p 间接定位 Local Ref3，但 p 和 Local Ref3 对 JNI 程序员不可见。

Local Reference导致内存泄漏

在以上论述基础上，我们通过分析错误实例 1 和实例 2，来分析 Local Reference 可能导致的内存泄漏，加深对 Local Reference 的深层理解。

分析错误实例 1：

局部变量str在每次循环中都被重新赋值，间接指向最新创建的Local Reference，前面创建的Local Reference 一直保留在 Local Ref 表中。

在实例 1 执行完第i次循环后，内存布局如图 3：

图 3. 执行i次循环后的内存布局

继续执行完第i+1次循环后，内存布局发生变化，如图 4：

图 4. 执行i+1次循环后的内存布局

图 4 中，局部变量 str 被赋新值，间接指向了Local Ref i+1。在native method运行过程中，我们已经无法释放Local Ref i占用的内存，以及Local Ref i所引用的第i个 string对象所占据的Java Heap内存。所以，native memory中Local Ref i被泄漏，Java Heap中创建的第 i个string对象被泄漏了。

也就是说在循环中，前面创建的所有i个Local Reference都泄漏了native memory的内存，创建的所有 i 个string对象都泄漏了Java Heap的内存。

直到native memory执行完毕，返回到Java程序时（N2J），这些泄漏的内存才会被释放，但是 Local Reference 表所分配到的内存往往很小，在很多情况下N2J之前可能已经引发严重内存泄漏，导致Local Reference表的内存耗尽，使JVM崩溃，例如错误实例 1。

分析错误实例 2：

实例 2 与实例 1 相似，虽然每次循环中调用工具函数CreateStringUTF(env)来创建对象，但是在CreateStringUTF(env)返回退栈过程中，只是局部变量被删除，而每次调用创建的Local Reference仍然存在Local Ref表中，并且有效引用到每个新创建的string对象。str局部变量在每次循环中被赋新值。

这样的内存泄漏是潜在的，但是这样的错误 在JNI程序员编程过程中却经常出现。通常情况，在触发out of memory之前，native method已经执行完毕，切换回 Java 环境，所有 Local Reference 被删除，问题也就没有显露出来。但是某些情况下就会引发out of memory，导致实例 1 和实例 2 中的JVM崩溃。

控制Local Reference生命期

因此，在JNI编程时，正确控制JNILocal Reference的生命期。如果需要创建过多的Local Reference，那么在对被引用的Java对象操作结束后，需要调用JNI function（如 DeleteLocalRef()），及时将JNILocal Reference从Local Ref表中删除，以避免潜在的内存泄漏。

总结

---

本文阐述了JNI编程可能引发的内存泄漏，JNI编程既可能引发Java Heap的内存泄漏，也可能引发native memory的内存泄漏，严重的情况可能使JVM运行异常终止。JNI软件开发人员在编程中，应当考虑以下几点，避免内存泄漏：

• native code本身的内存管理机制依然要遵循。
• 使用Global reference时，当native code不再需要访问Global reference时，应当调用JNI函数DeleteGlobalRef()删除Global reference和它引用的Java对象。Global reference管理不当会导致Java Heap的内存泄漏。
• 透彻理解Local reference，区分Local reference和native code的局部变量，避免混淆两者所引起的native memory的内存泄漏。
• 使用Local reference时，如果Local reference引用了大的Java对象，当不再需要访问Local reference时，应当调用JNI函数DeleteLocalRef()删除Local reference，从而也断开对Java对象的引用。这样可以避免Java Heap的out of memory。
• 使用Local reference时，如果在native method执行期间会创建大量的Local reference，当不再需要访问Local reference时，应当调用JNI函数DeleteLocalRef()删除Local reference。Local reference表空间有限，这样可以避免Local reference表的内存溢出，避免native memory的out of memory。
• 严格遵循JavaJNI规范书中的使用规则。

参考链接

---

在 JNI 编程中避免内存泄漏

类型擦除

---

Class c1 = new ArrayList<Integer>().getClass();
Class c2 = new ArrayList<String>().getClass(); 
System.out.println(c1 == c2);

/* Output
true
*/

显然在平时使用中，ArrayList<Integer>()和new ArrayList<String>()是完全不同的类型，但是在这里，程序却的的确确会输出true。

这就是Java泛型的类型擦除造成的，因为不管是ArrayList<Integer>()还是new ArrayList<String>()，都在编译器被编译器擦除成了ArrayList。 那编译器为什么要做这件事？原因也和大多数的Java让人不爽的点一样——兼容性。由于泛型并不是从Java诞生就存在的一个特性，而是等到SE5才被加 入的，所以为了兼容之前并未使用泛型的类库和代码，不得不让编译器擦除掉代码中有关于泛型类型信息的部分，这样最后生成出来的代码其实是『泛型无关』的， 我们使用别人的代码或者类库时也就不需要关心对方代码是否已经『泛化』，反之亦然。

在编译器层面做的这件事（擦除具体的类型信息），使得Java的泛型先天都存在一个让人非常难受的缺点：

在泛型代码内部，无法获得任何有关泛型参数类型的信息。

List<Integer> list = new ArrayList<Integer>();
Map<Integer, String> map = new HashMap<Integer, String>();
System.out.println(Arrays.toString(list.getClass().getTypeParameters()));
System.out.println(Arrays.toString(map.getClass().getTypeParameters()));

/* Output
[E]
[K, V]
*/

关于getTypeParameters()的解释：

Returns an array of TypeVariable objects that represent the type variables declared by the generic declaration represented by this GenericDeclaration object, in declaration order. Returns an array of length 0 if the underlying generic declaration declares no type variables.

我们期待的是得到泛型参数的类型，但是实际上我们只得到了一堆占位符。

public class Main<T> {

    public T[] makeArray() {
        // error: Type parameter 'T' cannot be instantiated directly
        return new T[5];
    }
}

我们无法在泛型内部创建一个T类型的数组，原因也和之前一样，T仅仅是个占位符，并没有真实的类型信息，实际上，除了new表达式之外，instanceof操作和转型（会收到警告）在泛型内部都是无法使用的，而造成这个的原因就是之前讲过的编译器对类型信息进行了擦除。

同时，面对泛型内部形如T var;的代码时，记得多念几遍：它只是个Object，它只是个Object……

public class Main<T> {

    private T t;

    public void set(T t) {
        this.t = t;
    }

    public T get() {
        return t;
    }

    public static void main(String[] args) {
        Main<String> m = new Main<String>();
        m.set("findingsea");
        String s = m.get();
        System.out.println(s);
    }
}

/* Output
findingsea
*/

虽然有类型擦除的存在，使得编译器在泛型内部其实完全无法知道有关T的任何信息，但是编译器可以保证重要的一点：内部一致性，也是我们放进去的是什么类型的对象，取出来还是相同类型的对象，这一点让Java的泛型起码还是有用武之地的。

代码片段四展现就是编译器确保了我们放在t上的类型的确是T（即便它并不知道有关T的任何类型信息）。这种确保其实做了两步工作：

• set()处的类型检验
• get()处的类型转换

这两步工作也成为边界动作。

public class Main<T> {

    public List<T> fillList(T t, int size) {
        List<T> list = new ArrayList<T>();
        for (int i = 0; i < size; i++) {
            list.add(t);
        }
        return list;
    }

    public static void main(String[] args) {
        Main<String> m = new Main<String>();
        List<String> list = m.fillList("findingsea", 5);
        System.out.println(list.toString());
    }
}

/* Output
[findingsea, findingsea, findingsea, findingsea, findingsea]
*/

代码片段五同样展示的是泛型的内部一致性。

擦除的补偿

---

如上看到的，但凡是涉及到确切类型信息的操作，在泛型内部都是无法共工作的。那是否有办法绕过这个问题来编程，答案就是显示地传递类型标签。

public class Main<T> { 
    public T create(Class<T> type) { 
        try { 
            return type.newInstance(); 
        } catch (Exception e) { 
            e.printStackTrace(); 
        } 
        return null; 
    } 
    public static void main(String[] args) { 
        Main<String> m = new Main<String>(); 
        String s = m.create(String.class); 
    } 
}

代码片段六展示了一种用类型标签生成新对象的方法，但是这个办法很脆弱，因为这种办法要求对应的类型必须有默认构造函数，遇到Integer类型的时候就失败了，而且这个错误还不能在编译器捕获。

进阶的方法可以用限制类型的显示工厂和模板方法设计模式来改进这个问题，具体可以参见《Java编程思想 （第4版）》P382。

public class Main<T> { 
    public T[] create(Class<T> type) { 
        return (T[]) Array.newInstance(type, 10); 
    } 
    public static void main(String[] args) {
        Main<String> m = new Main<String>(); 
        String[] strings = m.create(String.class); 
    } 
}

代码片段七展示了对泛型数组的擦除补偿，本质方法还是通过显示地传递类型标签，通过Array.newInstance(type, size)来生成数组，同时也是最为推荐的在泛型内部生成数组的方法。

参考链接

---

Java泛型：类型擦除
java泛型（二）、泛型的内部原理：类型擦除以及类型擦除带来的问题