小小饮水机，里面也有值得思考的东西。

* 起因
昨晚回到寝室感到口渴，顺手按下了门旁饮水机的加热开关，到洗漱间洗了把脸，拿着水杯出来接水，看到加热灯已经变成绿色（我们的饮水机的加热指示灯在加热过程中是红色的，加热结束后会变成绿色，我想大多数饮水机都是这样的）我就按下热水出水开关接热水，可是却不见热水流出，这时我才注意到原来水桶里已经没水了。当时想的是这样无水加热会不会烧坏饮水机，恰好旁边有一装满水的新桶，我快速将之换上，心里想着那个绿灯肯定会马上变红，可是等了半天绿灯还是绿灯，没有任何重新加热的迹象，我很是感到奇怪，我尝试着按下热水出水开关，烧开的热水不竭的流到我的杯子中，当时就是感到挺困惑的，但是也没多想，咕噜噜的喝着烧开的热水，真是解渴亚。

* 加热保护
今天早上在来公司路上，突然灵光一现，想到了这个问题：“这可能就是饮水机的加热保护在作怪”。实际上在我加热的时候饮水机里的加热槽里是有水的，但是为了防止用户将这里的水全部用光，导致无水加热，饮水机在用户没有换新桶之前是不会放出这里的水的，这也是在警告用户该换桶了。直到用户换完新桶，饮水机的担心解除了，才自然把水流到你的杯子中。

* 猜想饮水机加热关注点
其实饮水机只需关注是否有新水源，如果有，一切OK，你想加热就加热，你想出水就出水；一旦没有新水源了，你可以加热，但是你是喝不到热水的。

在一个朋友的书架上发现王森著的《Java深度历险》一书，看了书的前言了解该书是关于Java底层技术内幕的。怀着好奇心浏览了一下，谈不上有太多收获，但也记下了一些自认为有益的两点。

* Java xxx

我们在命令行下敲入：“java xxx”后会发生什么呢？

流程如下：
1.找到JRE；
2.找到JVM.dll；
3.启动JVM，并进行初始化；
4.产生Bootstrap Loader；
5.载入ExtClassLoader；（Ext – Extended）
6.载入AppClassLoader；
7.加载xxx类。

书中提到Bootstrap Loader、ExtClassLoader和AppClassLoader构成了Java的“类加载器继承体系–class loader hierarchy”,其中Bootstrap Loader是由C++编写的，其他两个是由Java写的。之所以成为“继承体系”是因为这三个loader之间是有联系的。Bootstrap Loader负责加载ExtClassLoader，后者ExtClassLoader就将其parent置为Bootstrap Loader。AppClassLoader较为特殊，虽然由Bootstrap载入，但是其parent却置为ExtClassLoader。其原因是为了实现“委托模型”。简述“委托模型”就是当类加载器有加载类的需求时，会先请求其parent使用其搜索路径帮助加载，如果其parent找不到，才使用自己的搜索路径进行加载。如上述所说当ExtClassLoader想载入AppClassLoader类时它首先请求其parent “Bootstrap Loader”帮忙，Bootstrap Loader将AppClassLoader载入后，由于这个载入是ExtClassLoader请求的，所以AppClassLoader的parent还是置为ExtClassLoader而不是Bootstrap Loader。

* 类的加载流程
类加载的时候遵循一个原则：“类加载器会依类的继承体系从上至下依次加载”。举个例子：“如果C继承了B并实现了接口I，而B有继承自A”，则类加载器在加载C时，加载的次序会是A->B->I->C，（注：interface会如同class一样被Java编译器编译为独立的.class文件）

其实我对底层的东西并未给与太多的关注，如果在哪个项目中需要我去了解底层的话，我会去很好的学习。