java读取.properties配置文件的几种方法

读取.properties配置文件在实际的开发中使用的很多，总结了一下，有以下几种方法（仅仅是我知道的）：
一、通过jdk提供的java.util.Properties类。
此类继承自java.util.HashTable，即实现了Map接口，所以，可使用相应的方法来操作属性文件，但不建议使用像put、putAll这两个方法，因为put方法不仅允许存入String类型的value，还可以存入Object类型的。因此java.util.Properties类提供了getProperty()和setProperty()方法来操作属性文件，同时使用store或save(已过时)来保存属性值（把属性值写入.properties配置文件）。在使用之前，还需要加载属性文件，它提供了两个方法：load和loadFromXML。
load有两个方法的重载：load(InputStream inStream)、load(Reader reader)，所以，可根据不同的方式来加载属性文件。
可根据不同的方式来获取InputStream，如：
1、通过当前类加载器的getResourceAsStream方法获取

InputStream inStream = TestProperties.class.getClassLoader().getResourceAsStream("test.properties");

2、从文件获取

InputStream inStream = new FileInputStream(new File("filePath"));

3、也是通过类加载器来获取，和第一种一样

InputStream in = ClassLoader.getSystemResourceAsStream("filePath");

4、在servlet中，还可以通过context来获取InputStream

InputStream in = context.getResourceAsStream("filePath");

5、通过URL来获取

URL url = new URL("path");
InputStream inStream = url.openStream();

读取方法如下：

Properties prop = new Properties();
prop.load(inStream);
String key = prop.getProperty("username");
//String key = (String) prop.get("username");

二、通过java.util.ResourceBundle类来读取，这种方式比使用Properties要方便一些。
1、通过ResourceBundle.getBundle()静态方法来获取（ResourceBundle是一个抽象类），这种方式来获取properties属性文件不需要加.properties后缀名，只需要文件名即可。

ResourceBundle resource = ResourceBundle.getBundle("com/mmq/test");//test为属性文件名，放在包com.mmq下，如果是放在src下，直接用test即可
String key = resource.getString("username");

2、从InputStream中读取，获取InputStream的方法和上面一样，不再赘述。

ResourceBundle resource = new PropertyResourceBundle(inStream);

    注意：在使用中遇到的最大的问题可能是配置文件的路径问题，如果配置文件入在当前类所在的包下，那么需要使用包名限定，如：test.properties入在com.mmq包下，则要使用com/mmq/test.properties（通过Properties来获取）或com/mmq/test（通过ResourceBundle来获取）；属性文件在src根目录下，则直接使用test.properties或test即可。

 

 

这里主要是总结使用getResourceAsStream方法和InputStream流去读取properties文件，使用getResourceAsStream方法去读取properties文件时需要特别注意properties文件路径的写法

关于getClass().getClassLoader()

 

 

InputStream   is   =   getClass().getClassLoader().getResourceAsStream("helloworld.properties");中getClass()和getClassLoader()都是什么意思呀.
getClass()：取得当前对象所属的Class对象  
getClassLoader()：取得该Class对象的类装载器
类装载器负责从Java字符文件将字符流读入内存，并构造Class类对象，在你说的问题哪里，通过它可以得到一个文件的输入流
getClass :
public final Class getClass()
Returns the runtime class of an object. That Class object is the object that is locked by static synchronized methods of the represented class.
Returns:
the object of type Class that represents the runtime class of the object.

getClassLoader
public ClassLoader getClassLoader()
Returns the class loader for the class. Some implementations may use null to represent the bootstrap class loader. This method will return null in such implementations if this class was loaded by the bootstrap class loader.
If a security manager is present, and the caller´s class loader is not null and the caller´s class loader is not the same as or an ancestor of the class loader for the class whose class loader is requested, then this method calls the security manager´s checkPermission method with a RuntimePermission("getClassLoader") permission to ensure it´s ok to access the class loader for the class.

If this object represents a primitive type or void, null is returned.

Returns:
the class loader that loaded the class or interface represented by this object.
Throws:
SecurityException - if a security manager exists and its checkPermission method denies access to the class loader for the class.
See Also:
ClassLoader, SecurityManager.checkPermission(java.security.Permission), RuntimePermission

Class.getClassLoader()的一个小陷阱：）
昨天我的code总在Integer.class.getClassLoader().getResource("*********");这一句抛出空指针异常，定位为getClassLoader()返回null，查了一下jdk的文档，原来这里还有一个陷阱：
jdk中关于getClassLoader（）的描述：
/**
     * Returns the class loader for the class. Some implementations may use
     * null to represent the bootstrap class loader. This method will return
     * null in such implementations if this class was loaded by the bootstrap
     * class loader.
     *
     * <p> If a security manager is present, and the caller's class loader is
     * not null and the caller's class loader is not the same as or an ancestor of
     * the class loader for the class whose class loader is requested, then
     * this method calls the security manager's <code>checkPermission</code>
     * method with a <code>RuntimePermission("getClassLoader")</code>
     * permission to ensure it's ok to access the class loader for the class.
     *
     * <p>If this object
     * represents a primitive type or void, null is returned.
．．．．．

上面的英文可以用下面的话来理解：

装载类的过程非常简单：查找类所在位置，并将找到的Java类的字节码装入内存，生成对应的Class对象。Java的类装载器专门用来实现这样的过程，JVM并不止有一个类装载器，事实上，如果你愿意的话，你可以让JVM拥有无数个类装载器，当然这除了测试JVM外，我想不出还有其他的用途。你应该已经发现到了这样一个问题，类装载器自身也是一个类，它也需要被装载到内存中来，那么这些类装载器由谁来装载呢，总得有个根吧？没错，确实存在这样的根，它就是神龙见首不见尾的Bootstrap ClassLoader. 为什么说它神龙见首不见尾呢，因为你根本无法在Java代码中抓住哪怕是它的一点点的尾巴，尽管你能时时刻刻体会到它的存在，因为java的运行环境所需要的所有类库，都由它来装载，而它本身是C++写的程序，可以独立运行,可以说是JVM的运行起点,伟大吧。在Bootstrap完成它的任务后，会生成一个AppClassLoader(实际上之前系统还会使用扩展类装载器ExtClassLoader，它用于装载Java运行环境扩展包中的类),这个类装载器才是我们经常使用的，可以调用ClassLoader.getSystemClassLoader() 来获得，我们假定程序中没有使用类装载器相关操作设定或者自定义新的类装载器，那么我们编写的所有java类通通会由它来装载，值得尊敬吧。AppClassLoader查找类的区域就是耳熟能详的Classpath，也是初学者必须跨过的门槛，有没有灵光一闪的感觉，我们按照它的类查找范围给它取名为类路径类装载器。还是先前假定的情况，当Java中出现新的类，AppClassLoader首先在类传递给它的父类类装载器，也就是Extion ClassLoader，询问它是否能够装载该类，如果能，那AppClassLoader就不干这活了，同样Extion ClassLoader在装载时，也会先问问它的父类装载器。我们可以看出类装载器实际上是一个树状的结构图，每个类装载器有自己的父亲，类装载器在装载类时，总是先让自己的父类装载器装载(多么尊敬长辈),如果父类装载器无法装载该类时，自己就会动手装载，如果它也装载不了，那么对不起，它会大喊一声：Exception，class not found。有必要提一句，当由直接使用类路径装载器装载类失败抛出的是NoClassDefFoundException异常。如果使用自定义的类装载器loadClass方法或者ClassLoader的findSystemClass方法装载类，如果你不去刻意改变，那么抛出的是ClassNotFoundException。

这里jdk告诉我们：如果一个类是通过bootstrap 载入的，那我们通过这个类去获得classloader的话，有些jdk的实现是会返回一个null的，比如说我用 new Object().getClass().getClassLoader()的话，会返回一个null，这样的话上面的代码就会出现NullPointer异常．所以保险起见我们最好还是使用我们自己写的类来获取classloader（"this.getClass().getClassLoader()“），这样一来就不会有问题。