1.GB2312对应的Charset是sun.nio.cs.ext.EUC_CN，而对应的CharsetDecoder编码类是sun.nio.cs.ext.DoubleByte。GB2312字符集有一个从char到byte的码表，不同的字符编码就是从这个码表找到与每个字符对应的字节，然后拼装成成byte数组。
2.可以直接调用JDK的com.sun.tools.javac.main.Main类来手动编译指定的类。
3.Javac在进行词法分析时会由JavacParser根据Java语言规范来控制什么顺序、什么地方应该出现什么Token。
4.ClassLoader
（1）Bootstrap ClassLoader，这个ClassLoader主要加载JVM自身工作所需要的类，这个ClassLoader完全是由JVM自己控制的，需要加载哪个类、怎么加载都由JVM控制，别人也访问不了这个类，所以这个ClassLoader仅仅是一个类加载工具而已，既没有更高一级的父加载器，也没有子加载器。
（2）ExtClassLoader，这个类加载器是JVM自身的一部分，但并不是JVM亲自实现的。它服务的特定目标在System.getProperty("java.ext.dirs")目录下。
（3）AppClassLoader，这个类加载器的父类是ExtClassLoader，System.getProperty("java.class.path")目录下的类都可以被这个类加载器加载，这个目录就是我们经常用到的CLASSPATH。
如果我们要实现在即的类加载器，不管你是直接实现抽象类ClassLoader，还是继承URLClassLoader类，或者其他子类，它的父加载器都是AppClassLoader，因为不管调用哪个父类构造器，创建的对象都必须最终调用getSystemClassLoader()作为父加载器。而getSystemClassLoader()方法获取到的正是AppClassLoader。
JVM加载class文件到内存有两种方式：
（1）隐式加载：就是不通过在代码里调用ClassLoader来加载需要的类，而是通过JVM来自动加载到需要的类到内存的方式。例如，当我们在类中继承或者引用某个类时，JVM在解析当前这个类时发现引用的类不在内存中，那么就自动将这些类加载到内存中。
（2）显式加载：相反的显式加载就是我们在代码中通过调用ClassLoader类来加载一个类的方式，例如，调用this.getClass.getClassLoader().loadClass()或者Class.forName()，或者我们自己实现的ClassLoader的findClass()方法等。
如何加载class文件
（1）第一个阶段是找到.class文件并把这个文件包含的字节码加载到内存中。
（2）第二个阶段又可以分为三个步骤，分别是字节码验证、Class类数据结构分析及相应的内存分配和最后的符号表的链接。
（3）第三阶段是类中静态属性和初始化赋值，以及静态块的执行等。
显式记载一个类通常有如下方式：
（1）通过类Class中的forName()方法。
（2）通过类ClassLoader中的loadClass()方法
（3）通过类ClassLoader中的findSystemClass()方法
在JVM的规范中描述了出现NoClassDefFoundError可能的情况就是使用new关键字、属性引用某个类、继承了某个接口或类，以及方法的某个参数中引用了某个类，这时会触发JVM隐式加载这些类时发现这些类不存在的异常。
5.JVM执行字节码指令是基于栈的架构，也就是所有的操作数必须先入栈，然后根据指令中的操作码选择从栈顶弹出若干个元素进行计算后再将结果压入栈中。
6.GC的日志输出有如下参数：
- -verbose:gc，可以辅助输出一些详细的GC信息。
- -XX:+PrintGCDetails，输出GC的详细信息。
- -XX:+PrintGCApplicationStoppedTime，输出GC造成应用程序暂停的时间。
- -XX:+PrintGCDateStamps，GC发生的时间信息。
- -XX:+PrintHeapAtGc，在GC前后输出堆中各个区域的大小。
- -Xloggc:[file]，将GC信息输出到单独的文件中。
jstat使用格式为jstat -gcutil [pid] [intervel] [count]
S0 表示Heap上的Survivor space0区已使用空间的百分比
S1 表示Heap上的Survivor space1区已使用空间的百分比
E 表示Heap上的Eden space区已使用空间的百分比
O 表示Heap上的Old space去已使用空间的百分比
P 表示Perm space区已使用空间的百分比
YGC 表示从应用程序启动到采样时发生Young GC的次数
YGCT 表示从应用程序启动到采样时Young GC所用的时间（单位为秒）
FGC 表示从应用程序启动到采样时发生Full GC的次数
FGCT 表示从应用程序启动到采样时Full GC所用的时间
（单位为秒）
GCT 表示从应用程序启动到采样时用于垃圾回收的总时间（单位为秒）
可通过命令jmap-dump:format=b,file[filename][pid]来记录下堆的内存快照，然后利用第三方工具来分析整个Heap的管理情况。
如果内存耗尽那么可能导致JVM直接垮掉，可以通过参数：-XX:+HeapDumpOnOutOfMemoryError来配置当内存耗尽时记录下内存快照，可以通过-XX:HeapDumpPath来指定文件的路径，这个文件的命名格式如java_[pid].hprof。
JVM退出一般会在工作目录下产生一个日志文件，也可以通过JVM参数来设定，如-XX:ErrorFile=/tmp/log/hs_error_%p.log
目前在Servlet中提供了6种两类事件的观察者接口，它们分别是EventListeners类型的ServletContextAttributeListener、ServletRequestAttributeListener、ServletRequestListener、HttpSessionAttributeListener和LifecycleListeners类型的ServletContextListener、HttpSessionListener。
当前Cookie有两个版本：Version 0 和Version 1，它们有两种设置响应头的标识，分别是"Set-Cookie" 和 'Set-Cookie2'。
同一个客户端每次和服务端交互时，不需要每次都传回所有的Cookie值，而是只要传回一个ID，这个ID是客户端第一次访问服务器时生成的，而且每个客户端是唯一的。这样每个客户端就有一个唯一的ID，客户端只要传回这个ID就行了，这ID通常是NAME为JESESSIONID的一个Cookie。
Session正常工作的三种方式：
- 基于URL Path Parameter，默认支持。
- 基于Cookie，如果没有修改Context容器的Cookie标识，则默认也是支持的。
- 基于SSL，默认不支持，只有connector.getAttribute("SSLEnabled")为TRUE是才支持。
Jetty主要有两种Handler类型。一种是HandlerWrapper，它可以将一个Handler委托给另外一个类去执行，如我们要将一个Handler加到Jetty中，那么就必须将这个Handler委托给Server去调用。配合ScopeHandler类我们可以拦截Handler的执行，在调用Handler之前或之后可以做另外一些事情，类似于Tomcat中的Valve。另一种Handler类型是HandlerCollection。这个Handler类可以将多个Handler组装在一起，构成一个Handler链，方便我们扩展。
Jetty作为一个独立的Servlet引擎，可以独立提供Web服务，但是它也可以与其他Web应用服务器集成，所以它可以基于两种协议工作，一种是HTTP，另一种是AJP。
设置Jetty的Connector实现类为org.eclipse.jetty.bi.SocketConnector，让Jetty以BIO的方式工作。Jetty在启动时将会创建BIO的工作环境，它会创建HttpConnection类来解析和封装HTTP1.1的协议，ConnectorEndPoint类是以BIO的处理方式处理连接请求的。ServerSocket用于建立Socket连接以接受和传送数据，Executor用于处理连接的线程池，它负责处理每一个请求队列中的任务。acceptorThread监听连接请求，一有Socket连接，它便将进入下面的处理流程。
Jetty创建接收连接的环境需要以下三个步骤：
（1）创建一个队列线程池，用于处理每个建立连接的任务，这个线程池可以由用户来指定，这和Tomcat是类似的。
（2）创建ServerSocket，用于准备接收客户端的Socket请求，以及客户端用来包装这个Socket的一些辅助类。
（3）创建一个或多个监听线程，用来监听访问端口是否有连接进来。