Hadoop Configuration配置类的分析
学习Hadoop Common模块，当然应该是从最简单，最基础的模块学习最好，所以我挑选了其中的conf配置模块进行学习。整体的类结构非常简单。
只要继承了Configurable接口，一般表明就是可配置的，可以执行相应的配置操作，但是配置的集中操作的体现是在Configuration这个类中。这个类中定义了很多的集合变量：
/**
* List of configuration resources.
*/
private ArrayList<Object> resources = new ArrayList<Object>();
/**
* List of configuration parameters marked <b>final</b>.
* finalParameters集合中保留的是final修饰的不可变的参数
*/
private Set<String> finalParameters = new HashSet<String>();
/**
* 是否加载默认资源配置
*/
private boolean loadDefaults = true;
/**
* Configuration objects
* Configuration对象
*/
private static final WeakHashMap<Configuration,Object> REGISTRY =
new WeakHashMap<Configuration,Object>();
/**
* List of default Resources. Resources are loaded in the order of the list
* entries
*/
private static final CopyOnWriteArrayList<String> defaultResources =
new CopyOnWriteArrayList<String>();
上面只是列举出了一部分，基本的用途都是拿来保存一些资源的数据。还有一个变量比较关键：
//资源配置文件中的属性会加载到Properties属性中来 private Properties properties;所有的属性变量都是存放到java中的Properties中存放，便于后面的直接存取。Property其实就是一个HashTable。我们按着Configuration加载的顺序来学习一下他的整个过程。首先当然是执行初始化代码块:
static{
//print deprecation warning if hadoop-site.xml is found in classpath
ClassLoader cL = Thread.currentThread().getContextClassLoader();
if (cL == null) {
cL = Configuration.class.getClassLoader();
}
if(cL.getResource("hadoop-site.xml")!=null) {
LOG.warn("DEPRECATED: hadoop-site.xml found in the classpath. " +
"Usage of hadoop-site.xml is deprecated. Instead use core-site.xml, "
+ "mapred-site.xml and hdfs-site.xml to override properties of " +
"core-default.xml, mapred-default.xml and hdfs-default.xml " +
"respectively");
}
//初始化中加载默认配置文件，core-site是用户的属性定义
//如果有相同,后者的属性会覆盖前者的属性
addDefaultResource("core-default.xml");
addDefaultResource("core-site.xml");
}学习过java构造函数的执行顺序的同学，应该知道初始化代码块中的代码的执行顺序是先于构造函数的，所以会执行完上面的操作，就来到了addDefaultResource():
/**
* Add a default resource. Resources are loaded in the order of the resources
* added.
* @param name file name. File should be present in the classpath.
*/
public static synchronized void addDefaultResource(String name) {
if(!defaultResources.contains(name)) {
defaultResources.add(name);
//遍历注册过的资源配置，进行重新加载操作
for(Configuration conf : REGISTRY.keySet()) {
if(conf.loadDefaults) {
conf.reloadConfiguration();
}
}
}
}把资源的名字加入到相应的集合中，然后遍历每个配置类，重新加载配置操作，因为默认资源列表改动了，所以要重新加载了，这个也好理解。这里简单介绍一下，每一个Configuration类初始化后，都会加入到REGISTRY集合中，这是一个static 变量，所以会保持全局统一的一个。然后把重点移到reloadConfiguration():
/**
* Reload configuration from previously added resources.
*
* This method will clear all the configuration read from the added
* resources, and final parameters. This will make the resources to
* be read again before accessing the values. Values that are added
* via set methods will overlay values read from the resources.
*/
public synchronized void reloadConfiguration() {
//重新加载Configuration就是重新将里面的属性记录清空
properties = null; // trigger reload
finalParameters.clear(); // clear site-limits
}操作非常简单，就是clear一些操作，也许这时候，你会想难道不用马上加载新的资源吗？其实这也是作者的一大设计，答案在后面。好的，程序执行到这里，初始化代码块的操作完成了，接下来就是构造函数的执行了:
/** A new configuration. */
public Configuration() {
//初始化是需要加载默认资源的
this(true);
}然后继续调用重载函数:
/** A new configuration where the behavior of reading from the default
* resources can be turned off.
*
* If the parameter {@code loadDefaults} is false, the new instance
* will not load resources from the default files.
* @param loadDefaults specifies whether to load from the default files
*/
public Configuration(boolean loadDefaults) {
this.loadDefaults = loadDefaults;
if (LOG.isDebugEnabled()) {
LOG.debug(StringUtils.stringifyException(new IOException("config()")));
}
synchronized(Configuration.class) {
//加载过的Configuration对象对会加入到REGISTRY集合中
REGISTRY.put(this, null);
}
this.storeResource = false;
}重点观察人家把当前初始化的Configuration类加入到全局REGISTRY里面了。
以上分析的代码都是前期的操作，那么比较关键的set/get这类和属性直接相关的方法怎么实现的，所以这个时候，必须要先了解Hadoop中的配置文件是怎样的格式存在于文件中的。比如HDFS的配置文件hdfs-site.xml;
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<!-- file system properties -->
<property>
<name>dfs.name.dir</name>
<value>/var/local/hadoop/hdfs/name</value>
<description>Determines where on the local filesystem the DFS name node
should store the name table. If this is a comma-delimited list
of directories then the name table is replicated in all of the
directories, for redundancy. </description>
<final>true</final>
</property>
<property>
<name>dfs.data.dir</name>
<value>/var/local/hadoop/hdfs/data</value>
<description>Determines where on the local filesystem an DFS data node
should store its blocks. If this is a comma-delimited
list of directories, then data will be stored in all named
directories, typically on different devices.
Directories that do not exist are ignored.
</description>
<final>true</final>
</property>
.......节点层级的关系不是很复杂，关键在每个Property节点保留name名字，value值，des对于此属性的描述，final标签用于判断此属性能不能被改变，为true代表无法变更，类似于java语言里的final关键字。了解完配置文件的结构之后，就可以继续往下看了，比如我要设置1个属性，set的一个小小的方法如下:
/**
* Set the <code>value</code> of the <code>name</code> property.
*
* @param name property name.
* @param value property value.
* 根据name设置属性值，属性键值对保存在property中
*/
public void set(String name, String value) {
getOverlay().setProperty(name, value);
getProps().setProperty(name, value);
}后面的setProperty就是Property的设置方法，jdk的API，所以关键就是前面获取getProps的方法，如何把文件中的属性加载到Property的变量中的。
/**
* 加载的时候采用了延时加载的策略
* @return
*/
private synchronized Properties getProps() {
if (properties == null) {
properties = new Properties();
//从资源中再次获取属性相关的数据
loadResources(properties, resources, quietmode);
if (overlay!= null) {
properties.putAll(overlay);
if (storeResource) {
for (Map.Entry<Object,Object> item: overlay.entrySet()) {
updatingResource.put((String) item.getKey(), "Unknown");
}
}
}
}
return properties;
}看了上面为NULL的判断，也许你就知道为什么刚刚的重新加载操作那么简单，就执行了clear操作就完了，就是等着后面真正要获取这个Property的时候在加载的，就是所谓的延时加载策略，类似于单例模式中的懒汉式模型。所以loadResources又是此实现的关键:
private void loadResource(Properties properties, Object name, boolean quiet) {
try {
//工厂模式获取解析xml文件对象，这里用的是doc解析方式
DocumentBuilderFactory docBuilderFactory
= DocumentBuilderFactory.newInstance();
//ignore all comments inside the xml file
docBuilderFactory.setIgnoringComments(true);
//allow includes in the xml file
docBuilderFactory.setNamespaceAware(true);
try {
docBuilderFactory.setXIncludeAware(true);
} catch (UnsupportedOperationException e) {
LOG.error("Failed to set setXIncludeAware(true) for parser "
+ docBuilderFactory
+ ":" + e,
e);
}
DocumentBuilder builder = docBuilderFactory.newDocumentBuilder();
.....
if (root == null) {
//获取xml中的节点进行获取，这里先获取了根节点
root = doc.getDocumentElement();
}
if (!"configuration".equals(root.getTagName()))
LOG.fatal("bad conf file: top-level element not <configuration>");
NodeList props = root.getChildNodes();
for (int i = 0; i < props.getLength(); i++) {
Node propNode = props.item(i);
if (!(propNode instanceof Element))
continue;
Element prop = (Element)propNode;
if ("configuration".equals(prop.getTagName())) {
//如果子节点是configuration，则再次递归调用loadResource()方法
loadResource(properties, prop, quiet);
continue;
}
if (!"property".equals(prop.getTagName()))
LOG.warn("bad conf file: element not <property>");
NodeList fields = prop.getChildNodes();
String attr = null;
String value = null;
boolean finalParameter = false;
for (int j = 0; j < fields.getLength(); j++) {
Node fieldNode = fields.item(j);
if (!(fieldNode instanceof Element))
continue;
//属性节点分3种判断，name,value,final
Element field = (Element)fieldNode;
if ("name".equals(field.getTagName()) && field.hasChildNodes())
attr = ((Text)field.getFirstChild()).getData().trim();
if ("value".equals(field.getTagName()) && field.hasChildNodes())
value = ((Text)field.getFirstChild()).getData();
if ("final".equals(field.getTagName()) && field.hasChildNodes())
//final参数需额外添加到finalParameters参数的集合中
finalParameter = "true".equals(((Text)field.getFirstChild()).getData());
}
// Ignore this parameter if it has already been marked as 'final'
if (attr != null) {
if (value != null) {
if (!finalParameters.contains(attr)) {
//在这步把上面去的值放入properties属性中
properties.setProperty(attr, value);
if (storeResource) {
updatingResource.put(attr, name.toString());
}
} else if (!value.equals(properties.getProperty(attr))) {
LOG.warn(name+":a attempt to override final parameter: "+attr
+"; Ignoring.");
}
}
if (finalParameter) {
finalParameters.add(attr);
}
}
}和上面我们看的实际配置文件一对照，就不难理解了，就是简单的doc解析xml文件，这里不过多了一些处理，比如final的参数要额外再做一下操作。加载完成之后，属性信息就被放到了Property中了，就达成了目标了。
下面我们说说get的属性获取操作，同样有别样的设计，他可不仅仅是getProps().get(name)这样的操作,因为有的时候，通过这样的操作还无法取出真正想要的值。比如下面这样的结构:
<property>
<name>dfs.secondary.namenode.kerberos.principal</name>
<value>hdfs/_HOST@${local.realm}</value>
<description>
Kerberos principal name for the secondary NameNode.
</description>
</property>
也许你会直接通过dfs.secondary.namenode.kerberos.principal这个name去获取值，然后获取的值就是hdfs/_HOST@${local.realm}，但是很显然这不是我们需要的值，因为中间还有
${local.realm}，这个其实代表的是另外的一个设置的值，有的时候更多的是系统变量的值，所以这一点告诉我们，在值的查找操作里面我们需要替换这些变量。
/**
* Get the value of the <code>name</code> property, <code>null</code> if
* no such property exists.
*
* Values are processed for <a href="#VariableExpansion">variable expansion</a>
* before being returned.
*
* @param name the property name.
* @return the value of the <code>name</code> property,
* or null if no such property exists.
*/
public String get(String name) {
return substituteVars(getProps().getProperty(name));
}所以Hadoop在获取值后又进行了一步值替换的操作，用到了正则表达式。
//需匹配的模式为\$\{[^\}\$ ]+\}，里面多的\是在java里进行转义
//$,{,}是正则表达式中的保留字，因此需要加\,此匹配可分解为
//'\$\'{匹配的是${的部分
//最后的'\}'匹配了结尾符}，这样就构成了初步的${....}的目标类型结构了
//中间[^\}\$ ]匹配了除了},$，空格除外的关键字
//+是1个修饰次数，保证中间的匹配至少为1次，也就是说中间至少有值存在
private static Pattern varPat = Pattern.compile("\\$\\{[^\\}\\$\u0020]+\\}");
private static int MAX_SUBST = 20;
private String substituteVars(String expr) {
//输入的属性匹配值，为空的话直接返回
if (expr == null) {
return null;
}
Matcher match = varPat.matcher("");
String eval = expr;
//避免循环迭代陷入死循环，这里强制最多MAX_SUBST20次的替换
for(int s=0; s<MAX_SUBST; s++) {
match.reset(eval);
//寻找模式是否匹配
if (!match.find()) {
return eval;
}
String var = match.group();
//找到之后去掉头尾的${，和},截取出中间部分
var = var.substring(2, var.length()-1); // remove ${ .. }
String val = null;
try {
//看看此属性是否为系统变量
val = System.getProperty(var);
} catch(SecurityException se) {
LOG.warn("Unexpected SecurityException in Configuration", se);
}
if (val == null) {
val = getRaw(var);
}
if (val == null) {
return eval; // return literal ${var}: var is unbound
}
// substitute
//然后取出对应的值进行替换，再次查找是否有${..}类型值的存在
eval = eval.substring(0, match.start())+val+eval.substring(match.end());
}
throw new IllegalStateException("Variable substitution depth too large: "
+ MAX_SUBST + " " + expr);
}关键的难点是对于${...}这种模式的匹配器的构造，像我这种平时对于正则表达式第一想到的是上网找的人来说，就比较难想到了。还有1个特殊处理就是为了避免替换之后还会存在${...}出现死循环，所以这里有次数的限制。get操作的实现就是如此。最后看看我对于Configuration做的2条不同情况下的流程分析图:
配置类代码的实现应该说是短小和精炼，以后开发大型系统的时候完全可以借鉴此类似的原理。