(2012-10-22 15:56:10)
Configuration类中的配置参数都是来自于Hadoop的配置文件中，而这些配置文件在Configuration类中被当做一个个资源 (Resource)，每个资源都包含了一组以XML格式存在的name/value对，事实上，这些资源每一个都是单独的XML文件，例如HBase安 装配置中提到过的core-site.xml等。对于Configuration类而言，最重要的就是提供访问配置信息的接口，该类提供了一系列的 Set/Get方法用于读写特定名称(name)的值(value)。此外，Configuration类除了提供加载默认配置文件的方法外，还提供了addResource方法加载指定的xml配置文件，这样就允许一些基于Hadoop的子项目甚至是用户自己定义的配置参数被加载使用。
addResource类共有4种方式加载指定的配置信息：
Ø String:加载指定文件名的配置文件，该文件须在Hadoop的classpath中。
Ø Path:直接加载本地文件系统上以该参数为完整路径的配置文件。
Ø URL: 指定配置文件的Url路径并加载。
Ø InputStream:从输入流中反序列化所得到的配置对象。
Configuration类在默认情况下，会按照顺序加载下列配置文件：
Ø core-default.xml:该文件包含了Hadoop的只读配置参数。
Ø core-site.xml:该文件即用户设置的Hadoop配置参数。
由于Configuration类同时提供了对参数的Set方 法，而处于集群的安全性等原因，管理员可能并不像某些参数在后期被改动，这时可以将配置文件中不希望被改动的参数设置为 final，Configuration类在加载配置参数后，就会禁止对声明为final的参数的改动。如下图所示，可以设置core-site.xml 中的fs.default.name参数为final，以禁止该值被修改。
值得注意的是，早期版本的Hadoop配置是通过hadoop- site.xml文件实现的，在近期的版本中，该配置文件已被弃用，而改用core-site.xml、mapred-site.xml和hdfs- site.xml结合来完成配置。因此，在载入配置文件时，Hadoop会检查在classpath中是否存在hadoop-site.xml，如果存在 则会在日志中输出一条DEPRECATED的Warnning信息。
在了解了Configuration类之后，我们再分析其子类HBaseConfiguration类。下图为 HBaseConfiguration类的类图，除了继承自Configuration类之外，该类还实现了一下私有或共有的方法。从功能上讲，该类也是 提供对HBase配置参数的访问。
从图中可以看到，该类有两个构造函数：
public HBaseConfiguration();
public HBaseConfiguration(finalConfiguration c);
这两个构造函数是用来实例化 HBaseConfiguration类的，然而只在早期版本中使用，目前我们分析的0.90.4以及后期版本中，这两个构造函数都已被启用。由于新的 HBaseConfiguration类中所有的成员变量和成员方法都被声明为static，因此该类已经被禁止实例化，而当我们需要使用 HBaseConfiguration对HBase的配置信息进行访问时，事实上获得的是一个Configuration类的实例。
privatestatic Configuration conf = null;
static{
conf = HBaseConfiguration.create();
}
显然，HBaseConfiguration.create()方法返回的是一个能够访问HBase配置信息的Configuration的实例。
publicstatic Configuration create() {
Configuration conf = new Configuration();
return addHbaseResources(conf);
}
create()方法中主要做两个操作：首先创建一个Configuration类的实例conf，然后调用addHbaseResources方法对conf实例进行处理并将处理后的conf实例返回给该方法的调用者。
进一步，我们再分析addHbaseResources方法会执行那些操作：
public static ConfigurationaddHbaseResources(Configuration conf) {
conf.addResource("hbase-default.xml");
conf.addResource("hbase-site.xml");
checkDefaultsVersion(conf);
checkForClusterFreeMemoryLimit(conf);
return conf;
}
首先，调用conf对象的addResource(Stringname)方法，依照次序加载如下配置文件：
Ø hbase-default.xml:该文件是hbase的默认配置参数。
Ø hbase-site.xml:该文件为用户对hbase的配置参数。
然后，调用 checkDefaultsVersion(Configurationconf)方法，该方法通过conf实例获取 hbase.defaults.for.version的值，即配置文件hbase-default.xml中的版本信息，同时获取当前运行的HBase 的版本信息，如果默认配置文件中的版本号不同于当前运行的HBase的版本号，则会抛出一个RuntimeException，报告配置文件与当前 HBase环境的版本不一致。
最后，调用checkForClusterFreeMemoryLimit(Configuration conf)方法，该方法通过conf实例获取两个参数：
Ø hbase.regionserver.global.memstore.upperLimit:RegionServer 中每个MemStore的内存上限比例，超过这个值，一个新的update操作将被挂起，并强制执行flush操作。默认值为0.4，表示最大比例为堆大 小的40%。
Ø hfile.block.cache.size:HFile文件的块缓存大小占堆内存大小的比例。默认值为0.2，表示最大比例为20%。
获取这两个参数的值后，该方法将判断这两个参数的总大小是否超过 堆内存大小的80%，如果这两个参数之和超过0.8，就会抛出一个RuntimeException，报告当前MemStore和BlockCache所 占堆内存比例超过要成功执行集群操作的阈值上限。这里参数之和不能超过0.8的原因，是由于在HConstants类中，定义了一个 HBASE_CLUSTER_MINIMUM_MEMORY_THRESHOLD常量，该常量的值为0.2，该值为集群成功启动所需要的最小空闲堆内存百 分比，即集群成功启动所需要的空余堆空间至少为堆大小的20%。因此，当MemStore和BlockCache所占堆空间比例超过80%时，将导致集群 无法成功启动