看了半天的hadoop源码，终于明白了hadoop是如何把本地的jar文件分发到每个TaskTracker上面了。
一般情况下，我们会使用下面的命令来运行一个hadoop任务：
hadoop jar abc.jar arg0 arg1 ...
这个命令实际上是转化成下面的命令来运行的
java org.apache.hadoop.util.RunJar abc.jar arg0 arg1 ...
在RunJar中，会读取abc.jar文件，然后尝试从manifest中提取"Main-Class"作为mainClass，如果manifest中没有指定，则把abc.jar之后的下一个参数当成mainClass。
接下来，RunJar会在本地创建一个临时目录（下面称为workDir，类似/tmp/hadoop-unjar...），然后把abc.jar解压到这个目录中。
然后，把wrokDir、workDir/classes和workDir/lib下的所有文件路径添加到一个变量中，然后使用URLClassLoader将这个变量指定的所有路径加载到当前线程。
最后，使用反射调用mainClass的main函数，进入用户自己的代码。
当我们的代码调用job.waitForCompletion时，会调用JobClient.copyAndConfigureFiles，把本地的jar文件拷贝到HDFS上面/tmp/hadoop/mapred/staging/<jobid>/job.jar/的目录下。
接下来我们来看TaskTracker是如何获取和使用abc.jar的。
TaskTracker获取到一个Task之后，会启动一个线程TaskLauncher来处理这个Task。在启动这个Task之前，会调用taskController.initializeJob来初始化Job，把Job相关的内容从HDFS上拷贝到本地（JobLocalizer.localizeJobJarFile负责拷贝jar并解压到本地workDir中）。
后面TaskRunner.getClassPaths把wrokDir、workDir/classes和workDir/lib下的所有文件路径添加到一个变量中，然后使用这个变量构造启动JVM的参数，最后启动一个新的JVM来运行Job。
从这个流程可以看出，我们jar中的根目录，classes目录，和lib下的所有文件都被添加到了执行环境（另外还有系统自身的环境变量CLASSPATH和Hadoop自身依赖的库）中。
因此，如果我们想要在我们的hadoop中添加一个外部的库，可以有两种方法：
1.把外部的jar解压了，然后将所有的.class与我们自己的代码打包在一起（maven-shade-plugin可以很轻松地帮我们做这件事）；
2.创建一个lib目录，把依赖的jar文件放在里面，然后把lib目录和我们的代码打包在一起。
最后，提一下-libjars参数。如果我们使用ToolRunner.run来启动我们的Job，那么可以使用-libjars来指定依赖的外部jar。
不过-libjars有一定的局限性，由于-libjars来指定依赖的外部jar是在ToolRunner.run中使用GenericOptionsParser来加载的，因此在调用ToolRunner.run之前，外部jar还没有加载，不能使用这些类，甚至import（直接或间接）也不行（JVM加载一个类时会先检查这个类所引用的其他类型是否都可以找得到）。如果搞不清楚外部jar在何时可以用，不建议使用-libjars。
当然在Map和Reduce阶段时，-libjars来指定依赖的外部jar就完全可以无限制地使用了。Hadoop会自动把-libjars来指定依赖的外部jar上传到HDFS上，每个Job在执行之前，这些jar会自动被拷贝到本地，并设置到classpath中。
本文的分析基于hadoop 1.0.3。