概述

在我们编写Spark Application的的过程中，会涉及到很多概念，下面会介绍一些基本概念用于更好地理解Spark的设计以及应用开发。

RDD（Resillent Distributed Dataset）

弹性数据集。它是Spark的基本数据结构，Spark中的所有数据都是通过RDD的形式进行组织。RDD是不可变的数据集合，不可变的意思是RDD中的每个分区数据是只读的。RDD数据集是要做逻辑分区的，每个分区可以单独在集群节点进行计算。

DAG（Directed Acycle Graph）

有向无环图。在图论中，如果一个有向图无法从有一个定点出发经过若干条边回到该点，则这个图是有向无环图。Spark中用DAG来表示RDD之间的血缘关系。

NarrowDependency

窄依赖，子RDD依赖于父RDD中固定的Partition。NarrowDependency分为OneToOneDependency和RangeDependency。

ShuffleDependency

Shuffle依赖，也称作宽依赖，子RDD可能对父RDD中所有的Partition都有依赖。子RDD对父RDD各个Partition的依赖取决于分区计算器（Partitioner）的算法。

Job

所谓一个Job，就是由一个RDD的action触发的动作，可以简单的理解为，当你需要执行一个RDD的action的时候，会生成一个job。

Stage

Stage是一个Job的组成单位，就是说，一个Job会被切分成1个或多个的Stage，然后各个Stage会按照执行顺序依次执行。至于Job根据什么标准来切分Stage，可以简单理解为按照是否需要shuffle来划分stage。当一个操作需要shuffle时，Spark就会将其划分为一个Stage。具体细节后续会有文章单独介绍。

Task

Task是Spark的执行单元，每个Stage都会包含一个或者一组Task。一般来说，数据有多少个partition就会有多少个Task。

Partition

Partition类似Hadoop的Split，是数据的一种划分方式，计算以Partition为单位进行的。Partition的划分依据有很多，也可以自己定义。例如HDFS的文件的划分方式就是按照HDFS Block大小来划分的。

Shuffle

Shuffle是Spark Application中一个非常重要的阶段。Shuffle用于打通map task（在Spark称为ShuffleMapTask）的输出与reduce task的任务（在Spark中就是ResultTask）的输入，map task的输出结果按照指定的分区策略分配给某一个分区的reduce task。

引言

Spark 作为一个基于内存的分布式计算引擎，其内存管理模块在整个系统中扮演着非常重要的角色。理解 Spark 内存管理的基本原理，有助于更好地开发 Spark 应用程序和进行性能调优。

一个Spark Application一般包括Driver和Executor两种JVM进程。Driver为主控进程，负责创建Context，提交Job，并将Job转换为Task，协调Executor间的Task执行。而Executor主要负责执行具体的计算任务，将结果返回Driver。 由于Driver的内存管理比较简单，和一般的JVM程序区别不大，所以本文重点分析Executor的内存管理。所以，本文提到的内存管理都是指Executor的内存管理。

堆内内存和堆外内存

Executor作为一个JVM进程，它的内存管理是基于JVM之上的。所以JVM的内存管理包括两种方式：

• 堆内内存管理（On-Heap）：对象分配的在JVM的堆上，对象会受GC束缚。
• 堆外内存管理（Off-Heap）：对象通过序列化分配在JVM之外的内存里，由应用程序对其进行管理，且不受GC束缚。这种内存管理方式可以避免频繁的 GC，但缺点是必须自己编写内存申请和释放的逻辑。

一般来说对象读写速度是：on-heap > off-heap > disk

内存空间分配

在Spark中，支持两种内存管理方式：静态内存管理（Static Memory Manager）和统一内存管理（Unified Memory Manager）。

Spark为Storage内存和Execution内存的管理提供了统一的接口MemoryManager，同一个 Executor内的任务都调用这个接口的方法来申请或释放内存。MemoryManager的实现上，Spark 1.6以前默认采用的是静态内存管理（StaticMemoryManager）的方式；而在Spark1.6以后，默认采用的是统一内存管理(UnifiedMemoryManager)的方式。在中Spark 1.6+中，可以通过spark.memory.useLegacyMode参数启用静态内存管理。

静态内存管理（Static Memory Manager）

静态内存管理机制下，Storage内存、Execution内存和其他内存的大小在 Spark 应用程序运行期间均为固定的，但用户可以应用程序启动前进行配置。由于这种分配已经逐渐被淘汰，但出于兼容性考虑，Spark依然保留下来。有兴趣的话，可以参考：https://blog.csdn.net/Lin_wj1995/article/details/79924542

这边主要讲下静态内存管理的弊端：静态内存管理机制实现起来较为简单，但如果用户不熟悉Spark的存储机制，或没有根据具体的数据规模和计算任务或做相应的配置，很容易造成Storage内存和Execution内存中的一方剩余大量的空间，而另一方却早早被占满，不得不淘汰或移出旧的内容以存储新的内容。

统一内存管理（Unified Memory Manager）

Spark 1.6之后引入了统一内存管理机制，该机制与静态内存管理的区别在于，Storage内存和Execution内存是共享一块内存空间的，双方可以互相占用对方的空闲区域。

堆内模型

默认情况下，Spark仅使用了堆内内存。堆内内存的大小由Spark Application启动时的–executor-memory或spark.executor.memory 参数配置。Executor内运行的并发任务共享JVM堆内内存。

Executor端的堆内内存区域大致可以分为以下四大块：

• Storage内存（Storage Memory）：主要用于存储Spark的cache数据，例如RDD的缓存、Broadcast变量，Unroll数据等。
• Execution内存（Execution Memory）：主要用于存放 Shuffle、Join、Sort、Aggregation等计算过程中的临时数据。
• 用户内存（User Memory）：主要用于存储 RDD 转换操作所需要的数据，例如 RDD 依赖等信息。
• 预留内存（Reserved Memory）：系统预留内存，会用来存储Spark内部对象。

内存分布如下图所示:

堆外模型

Spark 1.6 开始引入了Off-heap memory(SPARK-11389)。默认情况下，堆外内存是关闭的，我们可以通过spark.memory.offHeap.enabled参数启用，通过spark.memory.offHeap.size设置堆外内存大小。相比堆内内存，堆外内存的模型比较简单，只包括Storage内存和Execution内存，其分布如下图所示：

如果堆外内存被启用，那么Executor内将同时存在堆内和堆外内存，两者的使用互补影响，这个时候Executor中的Execution内存是堆内的Execution 内存和堆外的Execution内存之和，同理，Storage内存也一样。下图为Spark堆内和堆外示意图

动态占用机制

• 在程序提交时，会根据spark.memory.storageFraction参数设置Storage内存区域和Execution内存区域。
• 在程序运行时，如果双方的空间不不足（存储空间不足以放下一个完整的Block），则按照LRU规则存储到磁盘；如果己方空间不足而对方空间有空余，则借用对方的空间。
• Storage占用对方内存，可将占用的部分转存到硬盘，然后”归还”借用的空间。
• Execution占用对方内存，目前的实现是无法让对方”归还”的。因为Shuffle过程产生的文件在后面一定会被使用到，而Cache在内存的数据不一定在后面使用，归还内存可能会导致性能严重下降。

参考资料

• Difference between “on-heap” and “off-heap”
• Apache Spark 内存管理详解
• Apache Spark 统一内存管理模型详解
• Spark Memory Management

Spark 架构简介

Spark是一个master/slave架构的分布式系统，它的架构主要包含有

• Spark Driver
• Spark Executor
• Cluster Manager
  

一个Spark集群一般拥有单个的Driver和多个的Executor。Spark Driver和Executor都是独立运行的JVM进程，它们可以运行在单台机器上，也可以运行在多台机器上。

Spark Driver

Spark Driver是一个Spark Application的主入口，它可以用Scala，Python或者R进行编写。一个Spark Driver包含有一个SparkContext，这是整个Spark Application中最核心的组件。同时，还包含有DAGScheduler, TaskScheduler, BackendScheduler和BlockManager等组件用于将用户代码转换为Spark job运行在集群当中。Spark Driver的主要功能包括：

• 负责协调Job的运行和以及Cluster Manager进行交互。
• 将RDD转换为执行的DAG图，同时把DAG图分为不同的Stage
• 将Job切割成更小的执行单元，Task，由Executor执行。
• 启动一个HTTP Server，端口为4040。这个Web UI会把Spark Application运行时的信息展示出来。

Spark Executor

Spark Executor是Task的实际执行者。每个Application的Executor数量可以通过配置指定（Static Allocation）或者有Spark动态分配（Dynamic Allocation）。Executor的主要功能包括：

• 负责所有的数据处理工作
• 用于读取和写入外部数据源
• 缓存着计算过程中的数据

Cluster Manager

严格上说Cluster Manager并不是Spark的一部分，而是一个外部的Service（除了Standalone）。Spark Driver会和其进行交互用于从集群里获取资源（CPU，Memory等）。目前Spark支持4种Cluster Manager：

• Standalone：这是一种Spark自带的集群管理模式，设计也比较简单。
• Apache Mesos：Mesos是一种通用的集群资源管理服务，用于管理MapReduce应用或者其他类型的应用。
• Hadoop YARN ：YARN是由Hadoop 2.0引入的集群资源管理服务。
• Kubernetes：Kubernetes是一种管理containerized的应用的服务。Spark 2.3以后引入了对Kubernetes的支持。

至于选择使用哪一种Cluster Manager，完全取决于生产环境以及业务场景，并没有绝对的优劣。

《设计模式：可复用面向对象软件的基础》一书中提出了24中经典的设计模式，这些设计模式被广泛地运用于项目实战之中。这篇博客的重点并不在于讲解这些设计模式以及使用，而主要列举了在Java Core Libraries中间所用到的设计模式。Java Core Libraries中的API设计基本涵盖了GOF书中所提到的绝大部分设计模式，可以说是API设计的典范，非常值得借鉴和学习。

创建型模式

这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。

工厂模式（Factory Pattern）

• java.util.Calendar#getInstance()
• java.util.ResourceBundle#getBundle()
• java.text.NumberFormat#getInstance()
• java.nio.charset.Charset#forName()
• java.net.URLStreamHandlerFactory#createURLStreamHandler(String) (Returns singleton object per protocol)
• java.util.EnumSet#of()
• javax.xml.bind.JAXBContext#createMarshaller() and other similar methods

抽象工厂模式（Abstract Factory Pattern）

• javax.xml.parsers.DocumentBuilderFactory#newInstance()
• javax.xml.transform.TransformerFactory#newInstance()
• javax.xml.xpath.XPathFactory#newInstance()

单例模式（Singleton Pattern）

• java.lang.Runtime#getRuntime()
• java.awt.Desktop#getDesktop()
• java.lang.System#getSecurityManager()

建造者模式（Builder Pattern）

• java.lang.StringBuilder#append() (unsynchronized)
• java.lang.StringBuffer#append() (synchronized)
• java.nio.ByteBuffer#put() (also on CharBuffer, ShortBuffer, IntBuffer, LongBuffer, FloatBuffer and DoubleBuffer)
• javax.swing.GroupLayout.Group#addComponent()

原型模式（Prototype Pattern）

• java.lang.Object#clone()

结构型模式

这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式

适配器模式（Adapter Pattern）

• java.util.Arrays#asList()
• java.util.Collections#list()
• java.util.Collections#enumeration()
• java.io.InputStreamReader(InputStream) (returns a Reader)
• java.io.OutputStreamWriter(OutputStream) (returns a Writer)
• javax.xml.bind.annotation.adapters.XmlAdapter#marshal() and #unmarshal()

桥接模式（Bridge Pattern）

TODO

过滤器模式（Filter、Criteria Pattern）

组合模式（Composite Pattern）

• java.awt.Container#add(Component)
• javax.faces.component.UIComponent#getChildren()

装饰器模式（Decorator Pattern）

• All subclasses of java.io.InputStream, OutputStream, Reader and Writer have a constructor taking an instance of same type.
• java.util.Collections, the checkedXXX(), synchronizedXXX() and unmodifiableXXX() methods.
• javax.servlet.http.HttpServletRequestWrapper and HttpServletResponseWrapper

外观模式（Facade Pattern）

• javax.faces.context.FacesContext, it internally uses among others the abstract/interface types LifeCycle, ViewHandler, NavigationHandler and many more without that the enduser has to worry about it (which are however overrideable by injection).
• javax.faces.context.ExternalContext, which internally uses ServletContext, HttpSession, HttpServletRequest, HttpServletResponse, etc.

享元模式（Flyweight Pattern）

• java.lang.Integer#valueOf(int) (also on Boolean, Byte, Character, Short, Longand BigDecimal)

代理模式（Proxy Pattern）

• java.lang.reflect.Proxy
• java.rmi.*
• javax.ejb.EJB (explanation here)
• javax.inject.Inject (explanation here)
• javax.persistence.PersistenceContext

行为型模式

责任链模式（Chain of Responsibility Pattern）

• java.util.logging.Logger#log()
• javax.servlet.Filter#doFilter()

命令模式（Command Pattern）

• All implementations of java.lang.Runnable
• All implementations of javax.swing.Action

解释器模式（Interpreter Pattern）

• java.util.Pattern
• java.text.Normalizer
• All subclasses of java.text.Format
• All subclasses of javax.el.ELResolver

迭代器模式（Iterator Pattern）

• All implementations of java.util.Iterator (thus among others also java.util.Scanner!).
• All implementations of java.util.Enumeration

中介者模式（Mediator Pattern）

• java.util.Timer (all scheduleXXX() methods)
• java.util.concurrent.Executor#execute()
• java.util.concurrent.ExecutorService (the invokeXXX() and submit() methods)
• java.util.concurrent.ScheduledExecutorService (all scheduleXXX() methods)
• java.lang.reflect.Method#invoke()

备忘录模式（Memento Pattern）

• java.util.Date (the setter methods do that, Date is internally represented by a longvalue)
• All implementations of java.io.Serializable
• All implementations of javax.faces.component.StateHolder

观察者模式（Observer Pattern）

• java.util.Observer/java.util.Observable (rarely used in real world though)*
• All implementations of java.util.EventListener (practically all over Swing thus)
• javax.servlet.http.HttpSessionBindingListener
• javax.servlet.http.HttpSessionAttributeListener
• javax.faces.event.PhaseListener

状态模式（State Pattern）

• javax.faces.lifecycle.LifeCycle#execute() (controlled by FacesServlet, the behaviour is dependent on current phase (state) of JSF lifecycle)

空对象模式（Null Object Pattern）

TODO

策略模式（Strategy Pattern）

• java.util.Comparator#compare(), executed by among others Collections#sort().
• javax.servlet.http.HttpServlet, the service() and all doXXX() methods take HttpServletRequest and HttpServletResponse and the implementor has to process them (and not to get hold of them as instance variables!).
• javax.servlet.Filter#doFilter()

模板模式（Template Pattern）

• All non-abstract methods of java.io.InputStream, java.io.OutputStream, java.io.Reader and java.io.Writer.
• All non-abstract methods of java.util.AbstractList, java.util.AbstractSet and java.util.AbstractMap.
  javax.servlet.http.HttpServlet, all the doXXX() methods by default sends a HTTP 405 “Method Not Allowed” error to the response. You’re free to implement none or any of them.

访问者模式（Visitor Pattern）

• javax.lang.model.element.AnnotationValue and AnnotationValueVisitor
• javax.lang.model.element.Element and ElementVisitor
• javax.lang.model.type.TypeMirror and TypeVisitor
• java.nio.file.FileVisitor and SimpleFileVisitor
• javax.faces.component.visit.VisitContext and VisitCallback

参考资料

• http://www.runoob.com/design-pattern/design-pattern-intro.html
• https://stackoverflow.com/questions/1673841/examples-of-gof-design-patterns-in-javas-core-libraries

什么是ClassLoader

一个Java程序是由若干个class文件组成。当程序在运行时，即会调用该程序的一个入口函数来调用系统的相关功能，而这些功能都被封装在不同的class文件当中，所以经常要从这个class文件中要调用另外一个class文件中的方法，如果另外一个class文件不存在的，则会引发ClassNotFoundException。

程序在启动的时候，并不会一次性加载程序所要用的所有class文件，而是根据程序的需要，通过Java的类加载机制（ClassLoader）来动态加载某个class文件到内存当中的，从而只有class文件被载入到了内存之后，才能被其它class所引用。所以ClassLoader就是用来动态加载class文件到内存当中用的。

Java ClassLoader的体系结构

现在先看下ClassLoader的体系结构：

Bootstrap ClassLoader

BootStrap ClassLoader：称为启动类加载器，是Java类加载层次中最顶层的类加载器，负责加载JDK中的核心类库，如：rt.jar、resources.jar、charsets.jar等。

可以通过如下程序获得该classloader所加载的jar

1

System.out.println(System.getProperty("sun.boot.class.path"));

程序输出：

1

/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/sunrsasign.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/classes

如果是scala会在java的基础上额外加载几个jar。

1
2

scala> println(System.getProperty("sun.boot.class.path"))
/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/sunrsasign.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/classes:/Users/zhenlong/DevTools/scala/lib/akka-actor_2.11-2.3.10.jar:/Users/zhenlong/DevTools/scala/lib/config-1.2.1.jar:/Users/zhenlong/DevTools/scala/lib/jline-2.12.1.jar:/Users/zhenlong/DevTools/scala/lib/scala-actors-2.11.0.jar:/Users/zhenlong/DevTools/scala/lib/scala-actors-migration_2.11-1.1.0.jar:/Users/zhenlong/DevTools/scala/lib/scala-compiler.jar:/Users/zhenlong/DevTools/scala/lib/scala-continuations-library_2.11-1.0.2.jar:/Users/zhenlong/DevTools/scala/lib/scala-continuations-plugin_2.11.7-1.0.2.jar:/Users/zhenlong/DevTools/scala/lib/scala-library.jar:/Users/zhenlong/DevTools/scala/lib/scala-parser-combinators_2.11-1.0.4.jar:/Users/zhenlong/DevTools/scala/lib/scala-reflect.jar:/Users/zhenlong/DevTools/scala/lib/scala-swing_2.11-1.0.2.jar:/Users/zhenlong/DevTools/scala/lib/scala-xml_2.11-1.0.4.jar:/Users/zhenlong/DevTools/scala/lib/scalap-2.11.7.jar

Extension ClassLoader

Extension ClassLoader：称为扩展类加载器，负责加载Java的扩展类库，默认加载JAVA_HOME/jre/lib/ext/目下的所有jar。该类在sun.misc.launcher包中。

App ClassLoader

App ClassLoader：称为应用类加载器，也称为System ClassLoaer，负责加载应用程序CLASSPATH下的所有jar和class文件。该类也在sun.misc.launcher包中。

User-Defined ClassLoader

用户还可以根据需要定义自已的ClassLoader，而这些自定义的ClassLoader都必须继承自java.lang.ClassLoader类.

所有的ClassLoader都必须继承自java.lang.ClassLoader，而Bootstrap ClassLoader却不是。它不是一个普通的Java类，底层由C++编写，已嵌入到了JVM内核当中，当JVM启动后，Bootstrap ClassLoader也随着启动，负责加载完核心类库后，并构造Extension ClassLoader和App ClassLoader类加载器。

ClassLoader加载原理

ClassLoader使用的是双亲委托模型来搜索类的，每个ClassLoader实例都包含(而不是继承)一个父类加载器的引用。虚拟机内置的类加载器（Bootstrap ClassLoader）本身没有父类加载器，但可以用作其它ClassLoader实例的的父类加载器。

采用双亲委托机制加载类的时候采用如下的几个步骤：

1. 当前ClassLoader首先从自己已经加载的类中查询是否此类已经加载，如果已经加载则直接返回原来已经加载的类；
2. 当前classLoader的缓存中没有找到被加载的类的时候，委托父类加载器去加载，父类加载器采用同样的策略，首先查看自己的缓存，然后委托父类的父类去加载，一直到bootstrp ClassLoader.
3. 当所有的父类加载器都没有加载的时候，再由当前的类加载器加载，并将其放入它自己的缓存中，以便下次有加载请求的时候直接返回。
4. 如果它们都没有加载到这个类时，则抛出ClassNotFoundException异常。否则（找到），将为这个类生成一个类的定义，并将它加载到内存当中，最后返回这个类在内存中的Class实例对象；

总之，class的加载顺序为：cache -> parent classloader -> self.

使用双亲委托模型的好处：

1. 避免重复加载。当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。
2. 提高安全性。如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义的类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已经在启动时就被引导类加载器（Bootstrcp ClassLoader）加载，所以用户自定义的ClassLoader永远也无法加载一个自己写的String，除非你改变JDK中ClassLoader搜索类的默认算法。

在JVM在搜索类的时候，又是如何判定两个class是相同的呢？JVM在判定两个class是否相同时，不仅要判断两个类名是否相同，而且要判断是否由同一个类加载器实例加载的。只有两者同时满足的情况下，JVM才认为这两个class是相同的。就算两个class是同一份class字节码，如果被两个不同的ClassLoader实例所加载，JVM也会认为它们是两个不同class。比如有一个Java类SimpleClass.java，javac编译之后生成字节码文件SimpleClass.class，ClassLoaderA和ClassLoaderB这两个类加载器并读取了SimpleClass.class文件，并分别定义出了java.lang.Class实例来表示这个类，对于JVM来说，它们是两个不同的实例对象，但它们确实是同一份字节码文件，如果试图将这个Class实例生成具体的对象进行转换时，就会抛运行时异常java.lang.ClassCaseException，提示这是两个不同的类型。

如何自定义ClassLoader

何时需要自己定制ClassLoader？

1. 需要加载外部的class而这些class，默认的类加载器是加载不到的。例如，文件系统比较特殊或者需要从网络中加载一个class字节流等。
2. 需要实现class的隔离性。常用的web服务器，如weblogic、tomcat、jetty等都实现这样的类加载器。这些类加载器主要做到：
   1）实现加载Web应用指定目录下的jar和class。
   2）实现部署在容器中的Web应用程共同使用的类库的共享。
   3）实现部署在容器中各个Web应用程序自己私有类库的相互隔离。

如何自定义ClassLoader

1. 继承java.lang.ClassLoader
2. 覆盖findClass()方法

下面是一个自定义ClassLoader的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class MyClassLoader extends ClassLoader {
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        Class clazz = this.findLoadedClass(name);  // optional
        if (clazz == null) {
            byte[] classData = loadClassData(name);
            if (classData == null) {
                throw new ClassNotFoundException();
            }
            clazz = defineClass(name, classData, 0, classData.length);
        }
        return clazz;
    }

    private byte[] loadClassData(String name) {
        // TODO: load class data.
        return null;
    }
}

2015，忙碌的一年。工作上的繁忙以及生活上的琐碎，让时间悄然从我们的指缝间流逝。本打算在年底写下这篇总结，可是自己的拖延症又发作了，直接把这篇博文拖入了2016。

回顾

工作

今年（2015）有四分之一的时间都是在Boston度过的，体验了一把国外的生活，同时也开拓了眼界。经历Boston历史上罕见的暴风雪，也经历了只有9度的盛夏。在Garriot大神的带领下，玩转了Boston，学到很多国外的文化。总之Boston之行，是一次不错的体验。

和去年相比，今年整个team的工作内容有所侧重，不再像以前那么繁杂，更多的focus在产品本身。我从产品的一个组件做到另一个组件，从Server做到的底层Engine，从Java做到C++又回到Java。在不同的组件以及技术栈上来回切换着，偶尔也需要support客户去解决一些老产品的问题。年底我被调到另外一个项目组，主要从事和Hadoop以及Spark相关的开发。主要是老板觉得我之前有相关的项目背景比较适合这一块，主要是我个人面对C++有点怂，于是我就这么稀里糊涂地过去了。然后最近几个月，我接手了一些已解散了的团队的组件升级开发，全新的领域全新的技术栈搞得我是焦头烂额，终于在年底前有点眉目，基本完成了。希望后面可以专心玩Hadoop和Spark。

今年无论是我们Team的人员有所变动。Team里往日一起工作的小伙伴，有的离职另谋高就，有的被re-org到其他组去了。也许这些变化在他们那些老人看来早已稀疏平常了吧。我所能做也许就是做好自己，适应变化。望离开的小伙伴们各个都有好前程。

生活

年初和妹纸把婚礼办了，婚礼朴素而平常，感觉两个人只是把一个task勾掉而已，就是累了些，没有太大的感觉。

9月份还和妹纸休了婚假，去了趟向往已久的云南，走的是昆大丽香的经典路线（游记）。第一次长途旅行，第一次自己做攻略，第一次写游记。做攻略、写游记还是挺有成就感的，不仅方便了自己，还帮助了他人。读万卷书不如走万里路，旅行的过程中学到了很多，也交到了许多朋友。同时，我和妹纸也成立了一个家庭旅游基金，把每个月的收入放一部分到这个基金里面，一方面可以控制日常开支，另一方面能够更好的控制旅游预算。

其他方面？生活琐碎一言难尽…

学习

由于自己已经丢了写读书笔记的习惯，也不记得看了那些书。看来写读书笔记的习惯应该要重新拾起来。

这一年，感觉自己技术的水平没有太大提高，技术书籍看的也不多。确切说应该还是看了一些书的，只是实在没有太深的印象了。除了那本《Programming in Scala》，全英文还那么厚，啃到后面实在是要吐了。

反思

不以忙碌为借口 感觉这一年自己一直在忙忙碌碌中度过的，而又有一种一事无成的感觉。最近听到的一句很有道理的话：“忙碌的人往往也是最懒的人”。我一直以忙为借口，忽略身边的许多人和事。许多计划，也因为忙碌而一拖再拖。

遇事莫急躁 不知道是因为忙碌而急躁，还是因为急躁而忙碌。今年总是觉得自己遇事特别容易急躁，无论是在工作中，还是在生活中。学习也没有太多的耐心，总是希望能够快点学习一些高大上或者fashion的技术。直到前几日，和Garriot大神在吃饭的路上聊天，忽然意识到自己现在这个状态有点“浮沙造塔”的感觉。

从计划到习惯 写到这里想起了大学辅导员说过的一些话：“大学生活就是两个字：习惯”，“大学里面除了习惯以外还有两个字：专注”。其实我已经不记得辅导员是在什么样的情况下说了这些话的，不过习惯和专注这两个词我记得很清楚。可惜我在毕业后把这两个词留在的大学。养成一种新的习惯需要多少天？有一种说法是13天，也有一种说法是21天，Anyway，养成才是最重要的。今年我偶尔晚上也会出去跑步或者在家做做俯卧撑什么的，而每当工作一忙，这些事情就被丢在脑后。我也会经常计划着做些什么，然后计划永远赶不上变化。

专注于一件事 其实要做到专注于一件事是很难的，每天有太多的琐事等着我们，而我们却根本没法避免。我想这里提到专注两个字更多指的是在一定时间或者一个阶段仅专注一件事。例如，晚上打算学习或者coding，这个时候就应该避免他人打扰，尤其是不要看手机。再比如说，最近在学习某一门语言或者一项新的技术，就应该沿着某一领域专心的学习下去，而不应该心猿意马，毕竟新技术是永远学不完的。

亲人和朋友 自己觉得这一两年无论是对亲人，还是身边的朋友都冷淡了许多，主动联系也少了。然而，遇到困难的时候，却是多一个朋友多一条路。

展望

本打算把来年的展望写在这里，不过想想还是算了，写在这里不如记在脑子里面来得靠谱一些。我相信2016年必定会比2015年更加精彩，有许多未知的事情等着我们，想想还有点小激动啊。

Sublime Text是一个十分强大的文本编辑器，它支持Windows，Linux和Mac。Sublime Text在默认情况下就支持Markdown格式，本文想介绍的是如何增强Sublime Text使其更好的Markdown写作。

Package Control

想必大多数SublimeText的用户已经安装了Package Control这个神器了。如未安装，请参考：https://packagecontrol.io/installation

Markdown Preview

markdown preview这个插件可以使用户在浏览器中预览Markdown文件。

按下键Ctrl+Shift+p调出命令面板，找到Package Control: install Pakage这一项。搜索markdown preview，点击安装。

关于快捷键设置，可以在Preferences->Key Binding User中，加入

1
2
3
4
5
6
7
8
9

{ 
	"keys": ["alt+m"],
	"command": "markdown_preview",
	"args": 
	{ 
		"target": "browser"
		
	} 
}

语法高亮

默认SublimeText带的语法高亮对Markdown确实太少了，可以装一个Monokai Extended插件进行增强。在Package Control中搜索Monokai Extended并安装，然后在Preferences->Color Scheme中进行设置。

貌似已经很久没有写年终总结了，上次写已经是大学时候的事情了。仔细想想，写写总结还是有必要的，也许等二十年后回看这一篇一篇blog，才会想起自己一步一步如何走来的。

在2014年年初的时候，给自己定了个主题词：成长。一年过去了，个人认为自己或多或少还是有些成长的，无论在工作还是生活方面。

工作

这一年的工作中规中矩，虽说不是team里面表现最突出的一个，但至少没拉team的后腿，我已经很欣慰了。工作一年多来，一直觉得老板以及team里的小伙伴都非常nice，工作氛围也很好。上班嘛开心最总要，每天上班跟大家扯扯淡，周三晚上大家打打牌这日子还是不错的。

这一年里，由于项目需要自己的focus也一直在转变，自己就是team里的一块砖，哪里需要哪里搬。不过也学到了很多东西，接触了很多从来没有接触过的领域，如Big Data、Cloud以及Security等。不过，个人感觉很多都是浅尝辄止，希望来年能有一块能长期一直做下去的项目或者领域。

最后恭喜Big Data Discovery 1.0顺利release，说明这一年没瞎忙，散花。

技术

说到技术方面，感觉很难评价。这一年接触到很多新技术，如Hadoop、ZooKeeper以及Spark等最近非常火热的大数据相关的项目。不过，感觉大多都只是涉猎，很难说可以做到深入研究。个人感觉一个是没有实际需求去驱动，另一个就是这些项目都太大了，都不是什么分分钟能搞定的事情。

今年和几个志同道合的小伙伴成立了一个众成技术俱乐部，每个月大家一起交流技术问题，分享学到的东西，感觉还是很不错的。通过和小伙伴的交流和分享明显感觉到自己水平太low，书看太少，以至于都没什么货可以拿出来交流的。

俗话说：三天不读书，智商输给猪。接下来的一年估计多看书多敲代码了，到时候把看过的书单放到明年的总结里面。不过，重点应该还是放在Java、Scala以及分布式系统相关的一些技术上。虽说后面因为项目上的需要，得开始玩C++，可惜明显感觉自己的智商已经跟不上C++发展了，心塞。

生活

这一年，家里发生很多事情，希望接下来的一年一切安好。自己也于2014年12月27日，跟妹纸领了证。2014，爱你一世，从此肩上也多了一份责任，多了一份担当。

#展望

2015年，追求卓越！

Octopress是一个基于Jekyll静态页面生成器，多数用于Github Pages的生成。本文主要介绍Octopress在Windows以及Linux平台下的安装，本文的安装步骤基于Window 7以及Ubuntu 14.04。

Git安装

Git下载地址：http://git-scm.com/downloads

Ubuntu用户也可执行下面命令：

1

sudo apt-get install git

Ruby安装

Ruby下载地址:http://rubyinstaller.org/downloads/。这里需要注意，所选择的版本应为Ruby1.9.3或者更高，本文使用的是Ruby1.9.3。

Windows用户还需额外安装RubyDevKit，下载地址:http://rubyinstaller.org/downloads/

1
2
3

cd C:/RubyDevKit
ruby dk.rb init
ruby dk.rb install

安装后使用

1
2
3
4
5
6
7
8
9

# Octopress安装 
克隆Octopress源码，安装依赖。

``` bash
git clone git://github.com/imathis/octopress.git octopress
cd octopress
gem install bundler
bundle install

安装Octopress默认主题。

1

rake install

到目前为止，Octopress已经安装完成，可以使用

1
2
3
4

# Troubleshooting

Windows用户，在执行```rake generate```命令的过程中，可能会出现类似

warning: cannot close fd before spawn

1
2
3
4
5
6

的警告信息，导致静态页面生成失败。这是主要是由于pygments的版本与Windows不兼容导致的。可以尝试执行以下步骤进行修复：

``` bash
gem uninstall pygments.rb --version ">0.5.0"
gem install pygments.rb --version "=0.5.0"

在项目文件夹下修改Gemfile.lock文件

1

pygments.rb (0.6.0) => pygments.rb (0.5.0)

Zookeeper使用了一种称为Zab（Zookeeper Atomic Broadcast）的协议作为其一致性的核心。Zab协议是Paxos协议的一种变形，下面将展示一些协议的核心内容。

考虑到Zookeeper的主要操作数据状态，为了保证一致性，Zookeeper提出了两个安全属性：

• 全序（Total Order）：如果消息A在消息B之前发送，则所有Server应该看到相同结果。
• 因果顺序（Causal Order）：如果消息A在消息B之前发生（A导致了B），并且一起发送，则消息A始终在消息B之前被执行。

为了保证上述两个安全属性，Zookeeper使用了TCP协议和Leader。通过使用TCP协议保证了消息的全序的特性（先发先到），通过Leader解决了因果顺序(先到Leader先执行)。因为有了Leader，Zookeeper的架构就变成为：Master-Slave模式，但在该模式中Master（Leader）会Crash，因此，Zookeeper引入Leader选举算法，以保证系统的健壮性。

当Zookeeper Server收到写操作，Follower会将其转发给Leader，由Leader执行操作。Client可以直接从Follower上读取数据，如果需要读取最新数据，则需要从Leader节点读取，Zookeeper设计的读写比大致为2：1。

Leader执行写操作可以简化为一个两段式提交的transaction：

1. Leader发送proposal给所有的Follower。
2. 收到proposal后，Follower回复ACK给Leader，接受Leader的proposal.
3. 当Leader收到大多数的Follower的ACK后，将commit其proposal。

在这个过程中，proposal的确认不需要所有节点都同意，如果有2n+1个节点，那么只要有n个节点同意即可，也就是说Zookeeper允许n个节点down掉。任何两个多数派必然有交集，在Leader切换（Leader down）时，这些交集依然保持着最新的系统状态。如果集群节点个数少于n+1个时，Zookeeper将无法进行同步，也就无法继续工作。

Zab与Paxos

Zab的作者认为Zab与paxos并不相同，只所以没有采用Paxos是因为Paxos保证不了全序顺序：

Because multiple leaders can propose a value for a given instance two problems arise.
First, proposals can conflict. Paxos uses ballots to detect and resolve conflicting proposals.
Second, it is not enough to know that a given instance number has been committed, processes must also be able to figure out which value has been committed.

举个例子。假设一开始Paxos系统中的Leader是P1，他发起了两个事务{t1, v1}（表示序号为t1的事务要写的值是v1）和{t2, v2}，过程中Leader挂了。新来个Leader是P2，他发起了事务{t1, v1’}。而后又来个新Leader是P3，他汇总了一下，得出最终的执行序列{t1, v1’}和{t2, v2}。

这样的序列为什么不能满足ZooKeeper的需求呢？ZooKeeper是一个树形结构，很多操作都要先检查才能确定能不能执行，比如P1的事务t1可能是创建节点“/a”，t2可能是创建节点“/a/aa”，只有先创建了父节点“/a”，才能创建子节点“/a/aa”。而P2所发起的事务t1可能变成了创建“/b”。这样P3汇总后的序列是先创建“/b”再创建“/a/aa”，由于“/a”还没建，创建“a/aa”就搞不定了。

为了保证这一点，ZAB要保证同一个leader的发起的事务要按顺序被apply，同时还要保证只有先前的leader的所有事务都被apply之后，新选的leader才能在发起事务。