- Redkale 里大量使用了双亲委托模型，序列化的ConvertFactory、依赖注入的ResourceFactory、服务管理的WatchFactory均采用双亲委托模型。用于优先加载自定义的处理类，同时也保证两个同级的子Factory不会相互干扰。
+ Redkale 可以说是Java界最精简的框架，不到1M的jar包可以替代Tomcat、Spring/Spring Boot、Hibernate/MyBatis、JackJson/fastjson、Netty的集合，四两拨千斤。低调开源一年多，经过两次大的改善后终于达到让自己满意的地步。Redkale不仅仅提供简易的API，还附有很多不同于传统思维的设计思路。由于时间有限，一年多也没写入门教程，现在开始抽点时间写一些教程，希望能给想学Redkale的同学一点帮助。 废话不多说，下面进入正题。
ClassLoader类加载
+下载Redkale
- 双亲委托模型最经典的例子就是JVM的类加载器ClassLoader。每个ClassLoader实例都有一个父类加载器的引用（不是继承关系，是包含关系），虚拟机内置的类加载器（Bootstrap ClassLoader）本身没有父类加载器，但可以用作其它ClassLoader实例的的父类加载器。当一个ClassLoader实例需要加载某个类时，它会试图亲自搜索某个类之前，先把这个任务委托给它的父类加载器，这个过程是由上至下依次检查的，首先由最顶层的类加载器Bootstrap ClassLoader试图加载，如果没加载到，则把任务转交给Extension ClassLoader试图加载，如果也没加载到，则转交给App ClassLoader 进行加载，如果它也没有加载得到的话，则返回给委托的发起者，由它到指定的文件系统或网络等URL中加载该类。如果它们都没有加载到这个类时，则抛出ClassNotFoundException异常。否则将这个找到的类生成一个类的定义，并将它加载到内存当中，最后返回这个类在内存中的Class实例对象。
- ClassLoader采用双亲委托有两个好处：避免类的重复加载和保证类的安全性。由类加载的顺序可以看出父加载器加载过的类在子加载器中不会被重复加载，同时也保证了安全性，一些非系统的class是不可靠的，若定义一个恶意的java.io.File类覆盖JDK自带的类会带来不安全性。而使用双亲委托机制的话该File类永远不会被调用，因为委托BootStrapClassLoader加载后会加载JDK中的File类而不会加载自定义的这个。
+ 源码可以从 https://github.com/redkale 和 http://git.oschina.net/redkale/redkale 下载 。
+ jar包可以从 http://search.maven.org 和 https://repo1.maven.org/maven2/org/redkale/redkale/ 下载最新版本的包。
+ 当前最新版为 1.8， 下载 redkale-1.8.tar.gz 放在本地。
Redkale 双亲委托
+创建工程
- ConvertFactory、ResourceFactory、WatchFactory三者的双亲委托模型设计完全一样。下面以ConvertFactory为例说明，ConvertFactory的搜索顺序与ClassLoader相反，ClassLoader为了避免类的重复而先加载父加载器后加载子加载器，ConvertFactory为了优先加载自定义的Encoder和Decoder先搜索自身的ConvertFactory，找不到再从父ConvertFactory中搜索。 + 本人使用NetBeans很多年了，所以本教程以NetBeans来创建工程， 使用IntelliJ IDEA 或 Eclipse的同学请自行参考。
+
public final <E> Encodeable<W, E> findEncoder(final Type type) {
Encodeable<W, E> rs = (Encodeable<W, E>) encoders.get(type);
if (rs != null) return rs;
diff --git a/images/hello_01.png b/images/hello_01.png
new file mode 100644
index 000000000..34dc59bc6
Binary files /dev/null and b/images/hello_01.png differ
diff --git a/images/hello_02.png b/images/hello_02.png
new file mode 100644
index 000000000..404d7fee6
Binary files /dev/null and b/images/hello_02.png differ
diff --git a/images/hello_03.png b/images/hello_03.png
new file mode 100644
index 000000000..9b98fe3e7
Binary files /dev/null and b/images/hello_03.png differ
diff --git a/images/hello_04.png b/images/hello_04.png
new file mode 100644
index 000000000..60f7ca708
Binary files /dev/null and b/images/hello_04.png differ
diff --git a/images/hello_05.png b/images/hello_05.png
new file mode 100644
index 000000000..a79a0f9dd
Binary files /dev/null and b/images/hello_05.png differ
diff --git a/images/hello_06.png b/images/hello_06.png
new file mode 100644
index 000000000..deb318191
Binary files /dev/null and b/images/hello_06.png differ
diff --git a/images/hello_07.png b/images/hello_07.png
new file mode 100644
index 000000000..cc14abc7f
Binary files /dev/null and b/images/hello_07.png differ
diff --git a/images/hello_08.png b/images/hello_08.png
new file mode 100644
index 000000000..b622112e9
Binary files /dev/null and b/images/hello_08.png differ
diff --git a/images/hello_09.png b/images/hello_09.png
new file mode 100644
index 000000000..72ff1263f
Binary files /dev/null and b/images/hello_09.png differ
diff --git a/images/hello_10.png b/images/hello_10.png
new file mode 100644
index 000000000..5dfa97b59
Binary files /dev/null and b/images/hello_10.png differ
diff --git a/images/hello_11.png b/images/hello_11.png
new file mode 100644
index 000000000..6185bac58
Binary files /dev/null and b/images/hello_11.png differ
diff --git a/images/hello_12.png b/images/hello_12.png
new file mode 100644
index 000000000..c7270456c
Binary files /dev/null and b/images/hello_12.png differ