异常导致的退出会通过接口Abortable定义的abort()方法实现，Abortable实现类如下：
由以上类图可以看出HBaseAdmin的abort由于是client的访问，因此终止服务只需抛出异常即可，HConnection也是用于client，因此只需关闭连接，如果是zk的异常会在后续的使用中重新连接zk而不用关闭连接，其中重点的是HMaster、HRegionServer和ZookeeperWatcher三个子类：
HMaster
HMaster会出现异常(执行abort())停止的场景如下：
1.zk异常导致的master停止服务是最常见的场景，涉及操作包含但不限于以下：
a)Zk链接超时，超时时间通过zookeeper.session.timeout配置，默认为3分钟, 如果fail.fast.expired.active.master配置的值为false（默认为false），则不会立即abort，而是会尝试恢复zk的过期session；
b)在打开region后，需要从zk中删除opened节点，如果zk有该节点，但是删除失败；
c)在split region过程中，从zk删除split节点时；
d)Master节点改变时；
e)从zk中创建unassigned节点时；
f)在下线disabled的regoin时，从zk中删除disabled的region如果发生zk异常；
g)还有很多操作zk的节点时如果出现异常。
2.在assign时，如果设置region为offlined状态，但是region之前的状态不是closed或者offlined；
3.在assign时，如果无法从.META.表中读取region信息；
4.把新的hbase集群加入到正在运行的hbase集群时，如果zk的/hbase/unassigned节点没有数据；
5.使用线程池批量分配region时，如果出现未被捕获的异常，实现方式如下：
|
ThreadFactoryBuilder builder = new ThreadFactoryBuilder(); builder.setUncaughtExceptionHandler(getUncaughtExceptionHandler()); Executors. newFixedThreadPool(threadCount, builder.build()); protected UncaughtExceptionHandler getUncaughtExceptionHandler() { return new UncaughtExceptionHandler() { public void uncaughtException(Thread t, Throwable e) { server.abort("Uncaught exception in " + t.getName(), e); } }; } |
6.在启动master的服务线程时，出现了异常；
7.在hdfs中检查hbase日志路径时，发现了dead的server时，需从hdfs中读出log，如果出现io异常需要检查hdfs文件系统，如果fsOk状态为true，但是通过FSUtils工具类进行检查时出现io异常；
8.在校验并且分配-ROOT-的region时，如果zk异常，或者其它异常（其它异常会重试10次），比如：“-ROOT- is onlined on the dead server”。
HRegionServer
HRegionServer会出现异常停止(执行abort())服务的场景如下：
1.在读写hdfs时如果出现IOException异常，此时会发起hdfs的文件系统检查（checkFileSystem）1.
|
public boolean checkFileSystem() { if ( this.fsOk && this.fs != null) { try { FSUtils. checkFileSystemAvailable( this.fs); } catch (IOException e) { abort("File System not available", e); this.fsOk = false; } } return this.fsOk; } |
2.Regionserver的服务线程出现了未捕获异常；
3.在启动HRegionServer时出现异常；
4.在进行HLog回滚时，出现异常；
5.在flush memstore时，如果持久化失败，会重启RS，在重启中把hlog的内容重新加载到memstore；
6.出现zk异常，包括但不限于以下场景：
a)Zk链接超时，超时时间通过zookeeper.session.timeout配置，默认为3分钟，与master不同，如果zk操作不会重试；
b)启动HRegionServer时出现KeeperException异常；
c)在进行split操作时，如果出现异常会进行回滚操作，在回滚过程中需要从zk中删除region的spliting状态，如果删除时出现KeeperException或者回滚的其它操作出现异常；
d)在打开region时，出现了KeeperException异常；
e)在进行hbase集群复制时，很多与zk交互的操作出现KeeperException异常时均会导致abort；
7.在close region时，如果出现异常，比如：不能成功的flush memstore；
8.Flush memstore时，如果HLog发现该region已经在flush则会强制终止JVM，采用的是Runtime.getRuntime().halt(1)方法，该方法不会执行正常退出的关闭钩子，从而不会flush RS的所有region，也不会迁移region，只有等待ZK的session超时后master才会发现该RS不可用，做迁移工作。
总结
Hbase挂掉的可能性有很多，主要由zk或者hdfs的问题导致，因此zk、hdfs的可用对于hbase极其重要，关于zk：
1.zk如果停止了服务则在很多时候会导致master、rs挂掉，hbase集群基本上就失去了服务的能力，因此zk一定要是稳定可靠的，当client已经于rs建立了链接，这时zk挂掉，如果不进行split等小数与zk交互失败会导致触发rs的abort()的操作时rs还是可以提供服务的；
2.如果rs/master进行了长时间的gc或者改动了服务器时间，导致出现zk的session超时会导致rs/master停止服务，目前已经出现了2次因为服务器时间变化导致hbase停止服务的事故;
3.别轻易人为改变zk的hbase节点数据，master/rs在进行很多操作时会比较依赖zk的数据，如果发现不符合预期可能会导致master/rs停止服务，尤其是master。
Master通过ZK知道RS是否可用，一般情况下RS在停止服务时均会正常退出，在正常退出时会从ZK中删除/hbase/rs/$regionserver的节点，Master会监听该节点的被删除，从而较快的(速度取决于所有region关闭时间)对该RS负责的region进行重新分配，如果是强制退出，比如 kill -9或者出现HRegionServer挂掉的第8条时则只有等待ZK的session超时时才会删除RS在ZK的节点（RS在ZK中添加节点时采用的是CreateMode.EPHEMERAL模式，该模式创建的节点会在session关闭时自动删除），那时Master才会进行重新assign。
Kill RS的进程也是正常退出（不能使用kill -9强制退出），RS使用Runtime的addShutdownHook方法注册了jvm关闭钩子，在关闭钩子中会执行RS的退出逻辑，实际上hbase-daemon.sh的停止RS就是采用kill。