MapReduce剖析笔记之六：TaskTracker初始化任务并启动JVM过程

在上面一节我们分析了JobTracker调用JobQueueTaskScheduler进行任务分配，JobQueueTaskScheduler又调用JobInProgress按照一定顺序查找任务的流程，获得了任务之后，将任务封装为TaskTrackerAction数组返回的整个过程。TaskTracker通过心跳响应接收到了这个数组。本节我们继续分析，TaskTracker拿到了这个数组之后，如何对任务进行处理的。

1，TaskTracker在其方法offerService中，将得到的任务加入队列：

        TaskTrackerAction[] actions = heartbeatResponse.getActions();
。。。。。。。
        if (actions != null){
          for(TaskTrackerAction action: actions) {
            if (action instanceof LaunchTaskAction) {
              addToTaskQueue((LaunchTaskAction)action);
            } else if (action instanceof CommitTaskAction) {
              CommitTaskAction commitAction = (CommitTaskAction)action;
              if (!commitResponses.contains(commitAction.getTaskID())) {
                commitResponses.add(commitAction.getTaskID());
              }
            } else {
              addActionToCleanup(action);
            }
          }
        }

可见，返回的TaskTrackerAction对象有多种可能，最典型的是LaunchTaskAction，即启动一个任务；另外还有CommitTaskAction等。TaskTrackerAction是一个抽象类，其实现总共有5个，如下所示：

  public static enum ActionType {
    /** Launch a new task. */
    LAUNCH_TASK,
 
    /** Kill a task. */
    KILL_TASK,
 
    /** Kill any tasks of this job and cleanup. */
    KILL_JOB,
 
    /** Reinitialize the tasktracker. */
    REINIT_TRACKER,
 
    /** Ask a task to save its output. */
    COMMIT_TASK
  };

LaunchTaskAction表示启动任务，内部包含一个Task对象，即要启动的任务对象；

CommitTaskAction表示让一个正在执行中的任务提交其输出结果，其内部包含一个TaskAttemptID对象，对于某些Job来说，只有Map阶段而没有Reduce阶段，此时可以让其直接提交结果；

KillJobAction表示杀死属于该Job的任意任务，内部包含一个JobID；

KillTaskAction表示杀死一个任务，内部包含一个TaskAttemptID；

ReinitTrackerAction表示让TaskTracker重新初始化，无需带什么参数，只要随着心跳响应返回，对应的TaskTracker自然知道应该重新初始化。

我们对最典型的LaunchTaskAction进行分析，其内部的Task是一个抽象类，主要有MapTask和ReduceTask两种实现。在上面的代码中，addToTaskQueue将LaunchTaskAction按照Map或Reduce类型分别加入到不同的队列：

  private void addToTaskQueue(LaunchTaskAction action) {
    if (action.getTask().isMapTask()) {
      mapLauncher.addToTaskQueue(action);
    } else {
      reduceLauncher.addToTaskQueue(action);
    }
  }

mapLauncher和reduceLauncher都是TaskLauncher类型的对象，顾名思义用于Task的启动。TaskLauncher继承了Thread类，因此是一个线程类。其加入队列的代码为：

    public void addToTaskQueue(LaunchTaskAction action) {
      synchronized (tasksToLaunch) {
        TaskInProgress tip = registerTask(action, this);
        tasksToLaunch.add(tip);
        tasksToLaunch.notifyAll();
      }
    }

tasksToLaunch是一个任务链表：LinkedList<TaskInProgress>()，可见，我们再一次又看见了TaskInProgress，心跳响应时，双方交互的实际上是Task对象，自己内部维护的是TaskInProgress对象。通过registerTask这个方法，将其转换回来。其实其转换代码也简单：

  private TaskInProgress registerTask(LaunchTaskAction action,
      TaskLauncher launcher) {
    Task t = action.getTask();
    LOG.info("LaunchTaskAction (registerTask): " + t.getTaskID() +
             " task's state:" + t.getState());
    TaskInProgress tip = new TaskInProgress(t, this.fConf, launcher);
    synchronized (this) {
      tasks.put(t.getTaskID(), tip);
      runningTasks.put(t.getTaskID(), tip);
      boolean isMap = t.isMapTask();
      if (isMap) {
        mapTotal++;
      } else {
        reduceTotal++;
      }
    }
    return tip;
  }

在上面的注册代码中，创建了一个TaskInProgress对象，之后加入到两个映射表中：

  Map<TaskAttemptID, TaskInProgress> tasks = new HashMap<TaskAttemptID, TaskInProgress>();
  /**
   * Map from taskId -> TaskInProgress.
   */
  Map<TaskAttemptID, TaskInProgress> runningTasks = null;

映射表的索引是目前的任务ID，值即为刚刚创建的TaskInProgress对象。

之后，加入到tasksToLaunch对象中，并执行notifyAll方法，唤醒TaskLauncher线程（该线程可能处于睡眠等待中）处理队列里面的任务。

接下来，另一个线程，即TaskLauncher的run方法会处理这个对象。心跳线程即TaskTracker的主线程返回，继续等待执行后续的心跳。

2，TaskLauncher的run方法接着执行：

run方法的前半部分是从队列中获取任务：

          synchronized (tasksToLaunch) {
            while (tasksToLaunch.isEmpty()) {
              tasksToLaunch.wait();
            }
            //get the TIP
            tip = tasksToLaunch.remove(0);
            task = tip.getTask();
            LOG.info("Trying to launch : " + tip.getTask().getTaskID() +
                     " which needs " + task.getNumSlotsRequired() + " slots");
          }

如果为空，则调用wait进行等待；如果不为空，自然有人会通知自己（即notifyAll），之后，取出第一个任务并删除队列中的第一个元素。wait和notifyAll是JAVA任意一个对象都会具有的方法。

取出任务之后，需要判断是否有资源可用，使用IntWritable numFreeSlots进行判断，如果没有足够资源，则一直会等待：

            while (numFreeSlots.get() < task.getNumSlotsRequired()) {
。。。。。。。。。。。。。
              numFreeSlots.wait();
            }

而numFreeSlots的更新是TaskLauncher另一个方法中进行的：

    public void addFreeSlots(int numSlots) {
      synchronized (numFreeSlots) {
        numFreeSlots.set(numFreeSlots.get() + numSlots);
        assert (numFreeSlots.get() <= maxSlots);
        LOG.info("addFreeSlot : current free slots : " + numFreeSlots.get());
        numFreeSlots.notifyAll();
      }
    }

而该方法又被另一个方法调用：

    private synchronized void releaseSlot() {
      if (slotTaken) {
        if (launcher != null) {
          launcher.addFreeSlots(task.getNumSlotsRequired());
        }
        slotTaken = false;
      } else {
        // wake up the launcher. it may be waiting to block slots for this task.
        if (launcher != null) {
          launcher.notifySlots();
        }
      }
    }

releaseSlot表示释放资源，又是在kill和reportTaskFinished方法中调用：

    void reportTaskFinished(boolean commitPending) {
      if (!commitPending) {
        taskFinished();
        releaseSlot();
      }
      notifyTTAboutTaskCompletion();
    }

也就是说，当任务被杀掉或者执行完毕时，会释放资源，进而发出通告。

如果获得了足够的资源，则该变量会变化：

 numFreeSlots.set(numFreeSlots.get() - task.getNumSlotsRequired());

之后，如果任务可以执行（如果不可以执行还需要回收资源），进入startNewTask方法。在该方法里，会创建一个新线程进行任务的启动工作，上一个线程只是从队列里取出任务，判断资源是否充足等功能。启动了新线程后，它的使命结束了，返回去继续等待队列LinkedList<TaskInProgress>()中是否出现了新的TaskInProgress。

3，startNewTask创建的线程继续执行：

  void startNewTask(final TaskInProgress tip) throws InterruptedException {
    Thread launchThread = new Thread(new Runnable() {
      @Override
      public void run() {
        try {
          RunningJob rjob = localizeJob(tip);
          tip.getTask().setJobFile(rjob.getLocalizedJobConf().toString());
          launchTaskForJob(tip, new JobConf(rjob.getJobConf()), rjob);
        } catch (Throwable e) {
。。。。。
          try {
            tip.kill(true);
            tip.cleanup(false, true);
          } catch (IOException ie2) {
。。。。。。
        }
      }
    });
    launchThread.start();
  }

该线程中，首先执行localizeJob方法。这个方法用于初始化Job的目录。首先，执行addTaskToJob方法，将任务加入到正在运行作业的对象中，runningJobs是TaskTracker中的一个变量，记录了当前这个TaskTracker上面运行了哪些Job。

  Map<JobID, RunningJob> runningJobs = new TreeMap<JobID, RunningJob>();

runningJobs里面保存了Job ID和RunningJob之间的对应关系，RunningJob是一个类，记录了当前正在初始化的任务的信息。主要包含以下信息：

    private JobID jobid;
    private JobConf jobConf;
    private Path localizedJobConf;
    // keep this for later use
    volatile Set<TaskInProgress> tasks;
    //the 'localizing' and 'localized' fields have the following
    //state transitions (first entry is for 'localizing')
    //{false,false} -> {true,false} -> {false,true}
    volatile boolean localized;
    boolean localizing;
    boolean keepJobFiles;
    UserGroupInformation ugi;
    FetchStatus f;
    TaskDistributedCacheManager distCacheMgr;

即Job ID、Job Conf即配置参数、Job配置文件路径、该Job包含的任务集合（当前TaskTracker内的）以及一些用户权限等信息。

接下来需要对Job所在目录进行定位，使用initializeJob方法：

上一节我们在分析任务调度的时候，有一个obtainNewMapTaskCommon方法，该方法通过查找任务后，执行addRunningTaskToTIP方法，并调用addRunningTask方法，即创建MapTask或ReduceTask对象。此时会将任务的目录信息传进来，而最终一个任务的目录信息是在TaskInProgress的构造方法中传进来的。我们再回顾下Job的初始化过程，有以下代码：

    maps = new TaskInProgress[numMapTasks];
    for(int i=0; i < numMapTasks; ++i) {
      inputLength += splits[i].getInputDataLength();
      maps[i] = new TaskInProgress(jobId, jobFile,
                                   splits[i],
                                   jobtracker, conf, this, i, numSlotsPerMap);
    }

这里的jobFile即为任务所在的目录，实际上任务所在目录来源于作业所在目录，因此一个JobInProgress对象在创建的时候就会将目录信息记录下来，实际上，最终的文件目录是在Job初始化时的submitJobInternal方法传进来的。我们回顾以下关键代码：

        Path jobStagingArea = JobSubmissionFiles.getStagingDir(JobClient.this,
            jobCopy);
        JobID jobId = jobSubmitClient.getNewJobId();
        Path submitJobDir = new Path(jobStagingArea, jobId.toString());

这个目录即Staging目录，是根据一定规则自动生成的，最终位于HDFS的某个路径中。

我们回到initializeJob这个方法。因为Job提交时其实已经确定了目录，所以以下代码就是找到这个目录对应的文件系统：

    final JobID jobId = t.getJobID();
    final Path jobFile = new Path(t.getJobFile());
    final Configuration conf = getJobConf();
    FileSystem userFs = getFS(jobFile, jobId, conf);

这个文件系统就是HDFS中作业所在的Staging目录。Staging是集结地、驻留区的意思。用户在提交作业的时候，会将所需的jar文件、配置文件（conf、xml）、其它依赖的lib包、要处理数据的Split信息文件等全部上传到这个地方。

获得了这个目录后，接下来，TaskTracker的任务初始化过程会将上述处于HDFS中的文件拷贝到本地（如Linux）文件系统。使用localizeJobConfFile方法：

    FileStatus status = null;
    long jobFileSize = -1;
    try {
      status = userFs.getFileStatus(jobFile);
      jobFileSize = status.getLen();
    } catch(FileNotFoundException fe) {
      jobFileSize = -1;
    }
    Path localJobFile = lDirAlloc.getLocalPathForWrite(getPrivateDirJobConfFile(user,jobId.toString()), jobFileSize, fConf);
 
    // Download job.xml
    userFs.copyToLocalFile(jobFile, localJobFile);

lDirAlloc是一个LocalDirAllocator对象，主要用于本地目录的操作。getLocalPathForWrite方法：

  public Path getLocalPathForWrite(String pathStr, long size,
                                   Configuration conf,
                                   boolean checkWrite) throws IOException {
    AllocatorPerContext context = obtainContext(contextCfgItemName);
    return context.getLocalPathForWrite(pathStr, size, conf, checkWrite);
  }

AllocatorPerContext对象通过 obtainContext方法获得。这里面涉及到一个参数contextCfgItemName，该参数是LocalDirAllocator对象在创建的时候传入的：该对象本身是TaskTracker的一个变量：

    this.localDirAllocator = new LocalDirAllocator("mapred.local.dir");
 
  public LocalDirAllocator(String contextCfgItemName) {
    this.contextCfgItemName = contextCfgItemName;
  }

之后调用 context.getLocalPathForWrite方法，首先执行confChanged方法。在该方法里，有以下代码：

      String newLocalDirs = conf.get(contextCfgItemName);
      if (!newLocalDirs.equals(savedLocalDirs)) {
        String[] localDirs = conf.getStrings(contextCfgItemName);
        localFS = FileSystem.getLocal(conf);

此处，通过调用文件系统相关方法，会创建"mapred.local.dir"所指定的本地目录。

创建好了本地目录后，执行文件拷贝操作copyToLocalFile：

  public void copyToLocalFile(boolean delSrc, Path src, Path dst)
    throws IOException {
    FileUtil.copy(this, src, getLocal(getConf()), dst, delSrc, getConf());
  }

即job.xml文件被从HDFS中拷贝到TaskTracker所在的本地文件系统。该目录由配置文件"mapred.local.dir"指定。

另外，在这之前还有一些拷贝关于用户操作权限等文件：localizeJobTokenFile（与localizeJobConfFile过程类似）。

接下来对拷贝到本地的配置文件进行解析，得到JobConf对象：

final JobConf localJobConf = new JobConf(localJobFile);

并将这个信息加入到缓存中，因为localJobConf是根据某个任务拷贝过来的job.xml解析的，如果后面需要再用，则可以使用该缓存信息。TaskTracker里面维护了一个TrackerDistributedCacheManager distributedCacheManager对象，该对象里面维护了一个任务缓存：

  private Map<JobID, TaskDistributedCacheManager> jobArchives =
    Collections.synchronizedMap(
        new HashMap<JobID, TaskDistributedCacheManager>());

以及一个TaskController taskController。

首先将上面解析的任务配置参数加入到缓存中：

  public TaskDistributedCacheManager newTaskDistributedCacheManager(JobID jobId,
                                 Configuration taskConf) throws IOException {
    TaskDistributedCacheManager result = new TaskDistributedCacheManager(this, taskConf);
    jobArchives.put(jobId, result);
    return result;
  }

TrackerDistributedCacheManager以及TaskDistributedCacheManager 有什么意义呢？每个TaskTracker创建时会创建一个TrackerDistributedCacheManager对象，其主要作用是管理该机器上所有任务的Cache文件。而当任务在初始化时，会由TrackerDistributedCacheManager产生一个TaskDistributedCacheManager对象（如上面代码示例），用于管理本任务的Cache文件。有什么好处呢？比如，一个TaskTracker上可能会有一个Job的多个Task，这样，某个TaskDistributedCacheManager已经获取处理了某些Cache文件，则其他任务无需再处理。这里所谓的Cache文件，指的是从HDFS文件系统拷贝到本地文件系统的那些文件，本地的Linux系统相对于HDFS来说可以看做一种缓存，因为不能每次要访问某个参数，或者一个机器上的所有任务要访问Job信息都去HDFS中去获取和解析吧，这就是Distributed Cache分布式缓存的含义，因为有很多机器会拷贝这个文件。对于某个TaskTracker而言，通过拷贝到本地，不仅加速了后面的处理时间，也为其他任务做出了贡献。只是需要注意的是，如何维护本地的缓存信息和HDFS中的一致是需要解决的问题。Hadoop里设计了一个CacheFile类，里面包含了时间戳等信息，只要比较一下该时间戳以及HDFS中文件时间戳是否一致即可。

获得了缓存对象后，本地的Job配置会有一些更新，更新后写回到本地的配置文件：

          // Set some config values
          localJobConf.set(JobConf.MAPRED_LOCAL_DIR_PROPERTY,
              getJobConf().get(JobConf.MAPRED_LOCAL_DIR_PROPERTY));
          if (conf.get("slave.host.name") != null) {
            localJobConf.set("slave.host.name", conf.get("slave.host.name"));
          }
          resetNumTasksPerJvm(localJobConf);
          localJobConf.setUser(t.getUser());
 
          // write back the config (this config will have the updates that the
          // distributed cache manager makes as well)
          JobLocalizer.writeLocalJobFile(localJobFile, localJobConf);

接下来进入到taskController的initializeJob方法，进行后续的初始化。TaskController是一个抽象类，其实现是DefaultTaskController和LinuxTaskController。DefaultTaskController是默认的任务控制器，LinuxTaskController在Linux系统上使用，在用户权限设置等方面有些不同，可能是利用Linux的用户管理等等进行任务管理，以后有时间再研究，现在先来看默认的DefaultTaskController。

其initializeJob方法声明如下，可以看出，该方法从TaskTracker的私有空间拷贝证书文件到Job的私有空间；创建Job工作目录，下载job.jar文件并解压得到要执行的任务的.class文件，并更新配置。之后，创建一个JobConf配置对象，设置分布式缓存和用户日志目录等

  /**
   * This routine initializes the local file system for running a job.
   * Details:
   * <ul>
   * <li>Copies the credentials file from the TaskTracker's private space to
   * the job's private space </li>
   * <li>Creates the job work directory and set
   * {@link TaskTracker#JOB_LOCAL_DIR} in the configuration</li>
   * <li>Downloads the job.jar, unjars it, and updates the configuration to
   * reflect the localized path of the job.jar</li>
   * <li>Creates a base JobConf in the job's private space</li>
   * <li>Sets up the distributed cache</li>
   * <li>Sets up the user logs directory for the job</li>
   * </ul>
   * This method must be invoked in the access control context of the job owner
   * user. This is because the distributed cache is also setup here and the
   * access to the hdfs files requires authentication tokens in case where
   * security is enabled.
   * @param user the user in question (the job owner)
   * @param jobid the ID of the job in question
   * @param credentials the path to the credentials file that the TaskTracker
   * downloaded
   * @param jobConf the path to the job configuration file that the TaskTracker
   * downloaded
   * @param taskTracker the connection to the task tracker
   * @throws IOException
   * @throws InterruptedException
   */
  @Override
  public void initializeJob(String user, String jobid,
                            Path credentials, Path jobConf,
                            TaskUmbilicalProtocol taskTracker,
                            InetSocketAddress ttAddr
                            ) 

其输入参数主要有：用户、JobID、证书目录、Job配置文件目录、一个TaskUmbilicalProtocol对象，以及TaskTracker的IP地址信息，这里的TaskUmbilicalProtocol对象需要细说一下，TaskUmbilicalProtocol是和InterTrackerProtocol等等类似的一个RPC接口，我们前面分析过，再来总结一下：

1）JobClient和JobTracker之间存在一个RPC接口JobSubmissionProtocol，JobClient调用这个接口，JobTracker实现了这个接口。

2）JobTracker和TaskTracker之间存在一个RPC接口InterTrackerProtocol，TaskTracker调用这个接口，JobTracker实现了这个接口。

TaskUmbilicalProtocol也类似，不过是TaskTracker实现的，那么，谁来掉用呢？

Umbilical大致是脐带的意思，直观含义是连接胎儿和母体之间的重要通道。TaskTracker要启动一个Map或Reduce任务的时候，是通过启动另外一个JAVA虚拟机去运行这个任务，用户提交作业时，就是JobClient和JobTracker在打交道，JobTracker对这个作业初始化的过程会创建HDFS目录，将jar文件、分析处理的文件（即FileInputFormat.addInputPath里面指定的），生成Split信息文件等统统放到这个目录。在某个TaskTracker与自己心跳时，从作业队列挑选一些合适的任务，让TaskTracker运行，两者之间交互了Task的信息，TaskTracker接收到这个信息后，去HDFS目录里面将Job文件拷贝到本地，同时jar文件也拷贝下来，进行解压以后怎么运行呢？TaskTracker会启动一个JAVA虚拟机，这个JAVA虚拟机当然也是一个进程，不过称为TaskTracker进程的子进程，这个子进程和TaskTracker进程之间也需要交互一些信息，比如汇报状态等等，此时就导致了TaskUmbilicalProtocol这个RPC接口的出现。我们看看他有哪些方法：

  JvmTask getTask(JvmContext context) throws IOException;
 
  boolean statusUpdate(TaskAttemptID taskId, TaskStatus taskStatus,
      JvmContext jvmContext) throws IOException, InterruptedException;
 
  void reportDiagnosticInfo(TaskAttemptID taskid, String trace,
      JvmContext jvmContext) throws IOException;
 
  void reportNextRecordRange(TaskAttemptID taskid, SortedRanges.Range range,
      JvmContext jvmContext) throws IOException;
 
  boolean ping(TaskAttemptID taskid, JvmContext jvmContext) throws IOException;
 
  void done(TaskAttemptID taskid, JvmContext jvmContext) throws IOException;
 
  void commitPending(TaskAttemptID taskId, TaskStatus taskStatus,
      JvmContext jvmContext) throws IOException, InterruptedException;  
 
  boolean canCommit(TaskAttemptID taskid, JvmContext jvmContext) throws IOException;
 
  void shuffleError(TaskAttemptID taskId, String message, JvmContext jvmContext) throws IOException;
 
  void fsError(TaskAttemptID taskId, String message, JvmContext jvmContext) throws IOException;
 
  void fatalError(TaskAttemptID taskId, String message, JvmContext jvmContext)  throws IOException;
 
  MapTaskCompletionEventsUpdate getMapCompletionEvents(JobID jobId,
                                                       int fromIndex,
                                                       int maxLocs,
                                                       TaskAttemptID id,
                                                       JvmContext jvmContext)  throws IOException;
 
  void updatePrivateDistributedCacheSizes(org.apache.hadoop.mapreduce.JobID jobId,long[] sizes) throws IOException;

可见，主要是状态更新、错误信息上报、周期地ping、任务完成通知等等。

所以，现在可以理解，上面initializeJob方法中传入的TaskUmbilicalProtocol对象其实就是TaskTracker.this。

我们接下里分析initializeJob方法。

这个方法的主要功能上面已经进行了简单描述，来看一下细节。首先需要做的就是将TaskTracker从HDFS拷贝过来的文件进行二次拷贝，拷贝到作业所在的目录。这里使用了JobLocalizer类，这个类会创建以下目录：

/**
 * Internal class responsible for initializing the job, not intended for users.
 * Creates the following hierarchy:
 *   <li>$mapred.local.dir/taskTracker/$user</li>
 *   <li>$mapred.local.dir/taskTracker/$user/jobcache</li>
 *   <li>$mapred.local.dir/taskTracker/$user/jobcache/$jobid/work</li>
 *   <li>$mapred.local.dir/taskTracker/$user/jobcache/$jobid/jars</li>
 *   <li>$mapred.local.dir/taskTracker/$user/jobcache/$jobid/jars/job.jar</li>
 *   <li>$mapred.local.dir/taskTracker/$user/jobcache/$jobid/job.xml</li>
 *   <li>$mapred.local.dir/taskTracker/$user/jobcache/$jobid/jobToken</li>
 *   <li>$mapred.local.dir/taskTracker/$user/distcache</li>
 */

主要的代码是：

    FileSystem localFs = FileSystem.getLocal(getConf());
    JobLocalizer localizer = new JobLocalizer((JobConf)getConf(), user, jobid);
    localizer.createLocalDirs();
    localizer.createUserDirs();
    localizer.createJobDirs();
    JobConf jConf = new JobConf(jobConf);
    localizer.createWorkDir(jConf);
    //copy the credential file
    Path localJobTokenFile = lDirAlloc.getLocalPathForWrite(
        TaskTracker.getLocalJobTokenFile(user, jobid), getConf());
    FileUtil.copy(localFs, credentials, localFs, localJobTokenFile, false, getConf());
    //setup the user logs dir
    localizer.initializeJobLogDir();
    // Download the job.jar for this job from the system FS
    // setup the distributed cache
    // write job acls
    // write localized config
    localizer.localizeJobFiles(JobID.forName(jobid), jConf, localJobTokenFile, taskTracker);

这里比较重要的最后一行：localizeJobFiles，jar文件就是在这里处理的，进去看看。

执行的第一行代码就是localizeJobJarFile，前面已经把job.xml等文件拷贝到本地了，jar文件还没拷贝，此处就是做这个工作的。

主要代码为：

      // Here we check for five times the size of jarFileSize to accommodate for
      // unjarring the jar file in the jars directory
      Path localJarFile = lDirAlloc.getLocalPathForWrite(JARDST, 5 * jarFileSize, ttConf);
      //Download job.jar
      userFs.copyToLocalFile(jarFilePath, localJarFile);
      localJobConf.setJar(localJarFile.toString());
      // Also un-jar the job.jar files. We un-jar it so that classes inside
      // sub-directories, for e.g., lib/, classes/ are available on class-path
      RunJar.unJar(new File(localJarFile.toString()),
          new File(localJarFile.getParent().toString()));
      FileUtil.chmod(localJarFile.getParent().toString(), "ugo+rx", true);

在获得了本地的jar目录后，从HDFS中进行拷贝，并利用RunJar的unJar方法进行解压。JAVA里有JarFile这个类用于JAR打包和解压。顺便说一下，jar文件采用的就是ZIP格式，JarFile其实就是利用ZIP的解压方法，而JAVA中本身也有ZIP的解压方法，ZIP利用的是LZ系列字典压缩算法以及Huffman、游程编码等算法的融合。JarFile继承于java.util.zip.ZipFile这个类。

至此，TaskController的initializeJob方法结束，返回TaskTracker的initializeJob方法，并继续返回localizeJob方法。RunningJob这个对象初始化完毕，改变下面的值：

 rjob.localized = true;

并向其他线程执行通告：

      synchronized (rjob) {
        if (rjob.localizing) {
          rjob.localizing = false;
          rjob.notifyAll();
        }
      }
 
    synchronized (runningJobs) {
      runningJobs.notify(); //notify the fetcher thread
    }

localizeJob方法执行完毕，之后返回startNewTask方法。接下来执行launchTaskForJob方法：

  protected void launchTaskForJob(TaskInProgress tip, JobConf jobConf,
                                RunningJob rjob) throws IOException {
    synchronized (tip) {
      jobConf.set(JobConf.MAPRED_LOCAL_DIR_PROPERTY,
                  localStorage.getDirsString());
      tip.setJobConf(jobConf);
      tip.setUGI(rjob.ugi);
      tip.launchTask(rjob);
    }
  }

首先是设置一些任务参数，之后调用launchTask方法，在launchTask方法里，因为前面涉及的都是Job相关的配置信息，到了此时，Task本身的配置信息需要进行设置：

  /**
   * Localize the given JobConf to be specific for this task.
   */
  public void localizeConfiguration(JobConf conf) throws IOException {
    conf.set("mapred.tip.id", taskId.getTaskID().toString());
    conf.set("mapred.task.id", taskId.toString());
    conf.setBoolean("mapred.task.is.map", isMapTask());
    conf.setInt("mapred.task.partition", partition);
    conf.set("mapred.job.id", taskId.getJobID().toString());
  }

比如Task ID、是否是Map任务等等。

设置Task的状态为运行状态：

        if (this.taskStatus.getRunState() == TaskStatus.State.UNASSIGNED) {
          this.taskStatus.setRunState(TaskStatus.State.RUNNING);
        }

接下来会创建一个TaskRunner对象，TaskRunner 对象本身是TaskInProgress中的一个变量，其创建则是在MapTask或ReduceTask中实现的。

  @Override
  public TaskRunner createRunner(TaskTracker tracker,
                                 TaskTracker.TaskInProgress tip,
                                 TaskTracker.RunningJob rjob
                                 ) throws IOException {
    return new MapTaskRunner(tip, tracker, this.conf, rjob);
  }

TaskRunner是一个抽象类，主要有MapTaskRunner和ReduceTaskRunner两种实现。该抽象类继承于Thread，是一个线程类，并且在TaskRunner中实现了run方法。MapTaskRunner在创建过程中，利用父类构造方法，将一系列参数传进去：

  public TaskRunner(TaskTracker.TaskInProgress tip, TaskTracker tracker,
                    JobConf conf, TaskTracker.RunningJob rjob
                    ) throws IOException {
    this.tip = tip;
    this.t = tip.getTask();
    this.tracker = tracker;
    this.conf = conf;
    this.mapOutputFile = new MapOutputFile();
    this.mapOutputFile.setConf(conf);
    this.jvmManager = tracker.getJvmManagerInstance();
    this.localdirs = conf.getLocalDirs();
    taskDistributedCacheManager = rjob.distCacheMgr;
  }

比如Map任务之后的目录等，这里还有一个jvmManager对象，该对象是TaskTracker中的一个对象，每个TaskTracker一个，在TaskTracker初始化的时候会创建出来：

  public JvmManager(TaskTracker tracker) {
    mapJvmManager = new JvmManagerForType(tracker.getMaxCurrentMapTasks(), true, tracker);
    reduceJvmManager = new JvmManagerForType(tracker.getMaxCurrentReduceTasks(), false, tracker);
  }

其中：JvmManagerForType的构造方法如下，第一个参数是要管理的JAVA虚拟机的个数，而tracker.getMaxCurrentMapTasks()获得的就是为本TaskTracker配置的最大Map槽数。

    public JvmManagerForType(int maxJvms, boolean isMap,
        TaskTracker tracker) {
      this.maxJvms = maxJvms;
      this.isMap = isMap;
      this.tracker = tracker;
      sleeptimeBeforeSigkill =
        tracker.getJobConf().getLong(DELAY_BEFORE_KILL_KEY,
                                     DEFAULT_SLEEPTIME_BEFORE_SIGKILL);
    }

创建好了TaskRunner之后，即启动新线程：

        setTaskRunner(task.createRunner(TaskTracker.this, this, rjob));
        this.runner.start();

launchTask这个方法启动了TaskRunner之后，则返回launchTaskForJob方法，继续返回startNewTask方法。对tasksToLaunch中的其他TaskInProgress方法重复执行上面的初始化操作。startNewTask创建的局部线程已经结束。如果有新的任务到达，TaskLauncher会启动新的线程来执行上面的工作，下面进入到TaskRunner的run方法执行。

4，TaskRunner的run方法接力执行：

这个方法为JVM的启动提供命令行生成、环境变量、类库路径等信息。首先创建Task工作目录，注意上面的JobLocalizer类创建了一系列Job目录，这里创建的是Task相关的目录。

      final File workDir =
      new File(new Path(localdirs[rand.nextInt(localdirs.length)],
          TaskTracker.getTaskWorkDir(t.getUser(), taskid.getJobID().toString(),
          taskid.toString(),
          t.isTaskCleanupTask())).toString());
 
      String user = tip.getUGI().getUserName();

之后调用getClassPaths方法获取解压后的.class文件路径

  private static List<String> getClassPaths(JobConf conf, File workDir,
      TaskDistributedCacheManager taskDistributedCacheManager)
      throws IOException {
    // Accumulates class paths for child.
    List<String> classPaths = new ArrayList<String>();
    boolean userClassesTakesPrecedence =  conf.getBoolean(MAPREDUCE_USER_CLASSPATH_FIRST,false);
    if (!userClassesTakesPrecedence) {
      // start with same classpath as parent process
      appendSystemClasspaths(classPaths);
    }
    // include the user specified classpath
    appendJobJarClasspaths(conf.getJar(), classPaths);
    // Distributed cache paths
    classPaths.addAll(taskDistributedCacheManager.getClassPaths());
    // Include the working dir too
    classPaths.add(workDir.toString());
    if (userClassesTakesPrecedence) {
      // parent process's classpath is added last
      appendSystemClasspaths(classPaths);
    }
    return classPaths;
  }

总之，一个JAVA程序运行需要很多库目录，比如本地目录、JRE目录等，首先加入系统目录：

  private static void appendSystemClasspaths(List<String> classPaths) {
    for (String c : System.getProperty("java.class.path").split(
        SYSTEM_PATH_SEPARATOR)) {
      classPaths.add(c);
    }
  }

appendJobJarClasspaths方法加入到Job的jar文件所在的本地目录（已经从HDFS中拷贝下来了）。

之后，创建JAVA虚拟机运行所需要的参数：

      //  Build exec child JVM args.
      Vector<String> vargs = getVMArgs(taskid, workDir, classPaths, logSize);

说白了，就是产生一堆“java xxx -D ...”等等这个命令，比如一些参数示例，虚拟机内存占多大等等：

    //  <property>
    //    <name>mapred.map.child.java.opts</name>
    //    <value>-Xmx 512M -verbose:gc -Xloggc:/tmp/@taskid@.gc \
    //           -Dcom.sun.management.jmxremote.authenticate=false \
    //           -Dcom.sun.management.jmxremote.ssl=false \
    //    </value>
    //  </property>

首先找到JAVA虚拟机那个可执行文件在哪个目录（安装目录/bin），然后加进去，这自然是第一步。

    File jvm =                                  // use same jvm as parent
      new File(new File(System.getProperty("java.home"), "bin"), "java");
    vargs.add(jvm.toString());

另外，就是一些库文件目录等等，比如：

    Path childTmpDir = createChildTmpDir(workDir, conf, false);
    vargs.add("-Djava.io.tmpdir=" + childTmpDir);
 
    // Add classpath.
    vargs.add("-classpath");
    String classPath = StringUtils.join(SYSTEM_PATH_SEPARATOR, classPaths);
    vargs.add(classPath);

关键的是把要执行的class的类名写上：

vargs.add(Child.class.getName());  // main of Child

可以看出，执行的是Child这个类，这个类有一个Main方法。我们后面再看。

获得了JAVA运行参数后，继续获取环境变量：

      Map<String, String> env = new HashMap<String, String>();
      errorInfo = getVMEnvironment(errorInfo, user, workDir, conf, env, taskid,
                                   logSize);

比如LD_LIBRARY_PATH等等这些环境变量。

之后，执行launchJvmAndWait方法：

  void launchJvmAndWait(List <String> setup, Vector<String> vargs, File stdout,
      File stderr, long logSize, File workDir)
      throws InterruptedException, IOException {
    jvmManager.launchJvm(this, jvmManager.constructJvmEnv(setup, vargs, stdout,
        stderr, logSize, workDir, conf));
    synchronized (lock) {
      while (!done) {
        lock.wait();
      }
    }
  }

里面的核心方法是jvmManager.launchJvm：

  public void launchJvm(TaskRunner t, JvmEnv env
                        ) throws IOException, InterruptedException {
    if (t.getTask().isMapTask()) {
      mapJvmManager.reapJvm(t, env);
    } else {
      reduceJvmManager.reapJvm(t, env);
    }
  }

mapJvmManager和reduceJvmManager都是一个JvmManagerForType对象，前面提过，在TaskTracker初始化的时候会进行创建。执行JvmManagerForType的reapJvm方法，该方法中，有一个变量spawnNewJvm记录了是否应该启动一个新的JVM。spawn是产卵的意思，该标志的含义很明显，如果不满足一些条件，那么是不能启动虚拟机的，那么有哪些条件呢？

JvmManagerForType对象里面有几个映射表：

    //Mapping from the JVM IDs to running Tasks
    Map <JVMId,TaskRunner> jvmToRunningTask = new HashMap<JVMId, TaskRunner>();
    //Mapping from the tasks to JVM IDs
    Map <TaskRunner,JVMId> runningTaskToJvm = new HashMap<TaskRunner, JVMId>();
    //Mapping from the JVM IDs to Reduce JVM processes
    Map <JVMId, JvmRunner> jvmIdToRunner =  new HashMap<JVMId, JvmRunner>();
    //Mapping from the JVM IDs to process IDs
    Map <JVMId, String> jvmIdToPid = new HashMap<JVMId, String>();

jvmToRunningTask记录了JVMID和TaskRunner对象的关系；runningTaskToJvm则反过来记录；jvmIdToRunner记录了JVMID和JvmRunner的关系。注意这里有几个不同的对象：TaskRunner代表了要运行的任务；JvmRunner代表了要启动的虚拟机。

在判断spawnNewJvm变量时，首先获得当前已经运行的JVM：

int numJvmsSpawned = jvmIdToRunner.size();

如果numJvmsSpawned < maxJvms，那么表明目前启动的JVM还没达到最大值，可以启动：spawnNewJvm=true；

如果numJvmsSpawned >= maxJvms，则表明目前的数量已经至少等于最大可允许的JVM数量（=配置的Map或Reduce Slot数目），这种情况下按理来说可能不能启动了，不过也不一定。这里会对每一个JVM进行逐一判断，找找看，看哪个JVM适合处理这个任务。这是什么逻辑呢？有两种可能，一种可能是利用已经启动的JVM，判断代码如下：

          //look for a free JVM for this job; if one exists then just break
          if (jId.equals(jobId) && !jvmRunner.isBusy() && !jvmRunner.ranAll()){
            setRunningTaskForJvm(jvmRunner.jvmId, t); //reserve the JVM
            LOG.info("No new JVM spawned for jobId/taskid: " +
                     jobId+"/"+t.getTask().getTaskID() +
                     ". Attempting to reuse: " + jvmRunner.jvmId);
            return;
          }

如果一个JVM内的任务与要启动任务的Job ID一样（jId.equals(jobId)），且已经不忙了，即处于空闲状态（!jvmRunner.isBusy()），并且所有任务没有执行完毕（!jvmRunner.ranAll()），此时则将该任务（TaskRunner代表了要运行的任务）直接让该虚拟机执行，执行setRunningTaskForJvm方法：

    synchronized public void setRunningTaskForJvm(JVMId jvmId, TaskRunner t) {
      jvmToRunningTask.put(jvmId, t);
      runningTaskToJvm.put(t,jvmId);
      jvmIdToRunner.get(jvmId).setBusy(true);
    }

除了上面这种情况，还有一种情况就是看看能不能杀掉一个JVM，判断代码如下：

          if ((jId.equals(jobId) && jvmRunner.ranAll()) ||
              (!jId.equals(jobId) && !jvmRunner.isBusy())) {
            runnerToKill = jvmRunner;
            spawnNewJvm = true;
          }

即两者Job ID相同且JVM已经执行完毕了，此时可以杀掉这个JVM来执行新任务；或者两者Job ID不同且那个JVM处于空闲状态。这说明，一个新的任务并不是一定要启动一个新的JVM，可能会利用已有的JVM继续运行。

如果spawnNewJvm=true，则表示可以启动新的JVM：

      if (spawnNewJvm) {
        if (runnerToKill != null) {
          LOG.info("Killing JVM: " + runnerToKill.jvmId);
          killJvmRunner(runnerToKill);
        }
        spawnNewJvm(jobId, env, t);
        return;
      }

接下来我们看看spawnNewJvm这个方法，其代码较简单：

    private void spawnNewJvm(JobID jobId, JvmEnv env,
        TaskRunner t) {
      JvmRunner jvmRunner = new JvmRunner(env, jobId, t.getTask());
      jvmIdToRunner.put(jvmRunner.jvmId, jvmRunner);
      jvmRunner.setDaemon(true);
      jvmRunner.setName("JVM Runner " + jvmRunner.jvmId + " spawned.");
      setRunningTaskForJvm(jvmRunner.jvmId, t);
      LOG.info(jvmRunner.getName());
      jvmRunner.start();
    }

首先创建一个JvmRunner对象，表示要运行的JVM，将该JVM记录下来与JVMID与JVMRunner的关系。JVMID是一个JobID加上随机生成的整数组合成的一个对象。因为JvmRunner对象是一个线程类，所以最后一句启动了一个新线程：JVMRunner。此时，TaskRunner线程类的工作结束。

5，JVMRunner的run方法继续执行，其run方法也很简单，就一句话：

      @Override
      public void run() {
        try {
          runChild(env);
        } catch (InterruptedException ie) {
          return;
        } catch (IOException e) {
。。。。。。。。。。。
        } catch (Throwable e) {
。。。。。。。。。
        } finally {
          jvmFinished();
        }
      }

在方法runChild里，关键的一句是:

                exitCode = tracker.getTaskController().launchTask(user,
                    jvmId.jobId.toString(), taskAttemptIdStr, env.setup,
                    env.vargs, env.workDir, env.stdout.toString(),
                    env.stderr.toString());

于是进入DefaultTaskController的launchTask方法，该方法的作用是创建所有Task所需的目录，启动子JVM。

里面关键的代码是：

      // get the JVM command line.
      String cmdLine =
        TaskLog.buildCommandLine(setup, jvmArguments,
            new File(stdout), new File(stderr), logSize, true);
 
      // write the command to a file in the
      // task specific cache directory
      // TODO copy to user dir
      Path p = new Path(allocator.getLocalPathForWrite(
          TaskTracker.getPrivateDirTaskScriptLocation(user, jobId, attemptId),
          getConf()), COMMAND_FILE);
 
      String commandFile = writeCommand(cmdLine, rawFs, p);
      rawFs.setPermission(p, TaskController.TASK_LAUNCH_SCRIPT_PERMISSION);

cmdLin即生成要启动JVM的命令行字符串；第二句话是创建一个文件COMMAND_FILE，其值是COMMAND_FILE = "taskjvm.sh"，即创建一个脚本文件，之后将命令行字符串写入该脚本文件，并设置权限。

最后，做好了这些准备工作后，执行脚本：

      shExec = new ShellCommandExecutor(new String[]{
          "bash", commandFile},
          currentWorkDirectory);
      shExec.execute();

ShellCommandExecutor是一个脚本命令的执行类，execute方法将执行以下代码：

    /** Execute the shell command. */
    public void execute() throws IOException {
      this.run();
    }
 
  /** check to see if a command needs to be executed and execute if needed */
  protected void run() throws IOException {
    if (lastTime + interval > System.currentTimeMillis())
      return;
    exitCode = 0; // reset for next run
    runCommand();
  }

因此，进入runCommand方法，该方法使用了JAVA中提供的一个类：java.lang.ProcessBuilder，这个类用于创建操作系统进程。

首先设置环境变量等：

    if (environment != null) {
      builder.environment().putAll(this.environment);
    }
    if (dir != null) {
      builder.directory(this.dir);
    }

然后到了启动JVM的最关键一步，启动进程：

    process = builder.start();

等待进程运行：

      // wait for the process to finish and check the exit code
      exitCode  = process.waitFor();

接下来就是新进程的运行，启动的是Child这个类的Main方法：

  public static void main(String[] args) throws Throwable {
    LOG.debug("Child starting");
。。。。。。

这个执行较长，我们留作下一节分析。

总结一下，本节主要分析了JobTracker将任务调度给TaskTracker后，主要执行了5步操作，对应于5个线程：

1）TaskTracker调用addToTaskQueue加入TaskLauncher（mapLauncher和reduceLauncher）的队列。在这个过程中，会创建对应的TaskInProgress对象加入到队列List<TaskInProgress> tasksToLaunch中，然后返回（这一部分操作是由TaskTracker的心跳线程执行的）；

2）TaskLauncher这个线程类的run会不停地等待新的TaskInProgress，如果出现新的任务，进入startNewTask方法，startNewTask会创建一个新线程，TaskLauncher这个线程类返回去等待新的TaskInProgress任务；

3）startNewTask中的局部线程：从HDFS拷贝相应文件至本地等操作，该线程还会创建一个TaskRunner线程类，接着由其run方法执行；

4）TaskRunner线程类的run方法，负责获取JVM所需的参数信息，又启动JvmRunner这个线程类的run方法；

5）JvmRunner线程类的run方法，负责将JVM启动所需的命令写入一个脚本文件，执行该脚本文件，在另外一个进程中执行了Child的Main方法。

至于该Main进行了什么操作，留作后续分析。