Java 8 推出了全新的日期时间API，在教程中我们将通过一些简单的实例来学习如何使用新API。
Java处理日期、日历和时间的方式一直为社区所诟病，将 java.util.Date设定为可变类型，以及SimpleDateFormat的非线程安全使其应用非常受限。
新API基于ISO标准日历系统，java.time包下的所有类都是不可变类型而且线程安全。
Java 8 中的 LocalDate 用于表示当天日期。和java.util.Date不同，它只有日期，不包含时间。当你仅需要表示日期时就用这个类。
package com.shxt.demo02;
import java.time.LocalDate;
public class Demo01 {
public static void main(String[] args) {
LocalDate today = LocalDate.now();
System.out.println("今天的日期:"+today);
}
}package com.shxt.demo02;
import java.time.LocalDate;
public class Demo02 {
public static void main(String[] args) {
LocalDate today = LocalDate.now();
int year = today.getYear();
int month = today.getMonthValue();
int day = today.getDayOfMonth();
System.out.println("year:"+year);
System.out.println("month:"+month);
System.out.println("day:"+day);
}
}我们通过静态工厂方法now()非常容易地创建了当天日期，你还可以调用另一个有用的工厂方法LocalDate.of()创建任意日期， 该方法需要传入年、月、日做参数，返回对应的LocalDate实例。这个方法的好处是没再犯老API的设计错误，比如年度起始于1900，月份是从0开 始等等。
package com.shxt.demo02;
import java.time.LocalDate;
public class Demo03 {
public static void main(String[] args) {
LocalDate date = LocalDate.of(2018,2,6);
System.out.println("自定义日期:"+date);
}
}package com.shxt.demo02;
import java.time.LocalDate;
public class Demo04 {
public static void main(String[] args) {
LocalDate date1 = LocalDate.now();
LocalDate date2 = LocalDate.of(2018,2,5);
if(date1.equals(date2)){
System.out.println("时间相等");
}else{
System.out.println("时间不等");
}
}
}package com.shxt.demo02;
import java.time.LocalDate;
import java.time.MonthDay;
public class Demo05 {
public static void main(String[] args) {
LocalDate date1 = LocalDate.now();
LocalDate date2 = LocalDate.of(2018,2,6);
MonthDay birthday = MonthDay.of(date2.getMonth(),date2.getDayOfMonth());
MonthDay currentMonthDay = MonthDay.from(date1);
if(currentMonthDay.equals(birthday)){
System.out.println("是你的生日");
}else{
System.out.println("你的生日还没有到");
}
}
}只要当天的日期和生日匹配，无论是哪一年都会打印出祝贺信息。你可以把程序整合进系统时钟，看看生日时是否会受到提醒，或者写一个单元测试来检测代码是否运行正确。
package com.shxt.demo02;
import java.time.LocalTime;
public class Demo06 {
public static void main(String[] args) {
LocalTime time = LocalTime.now();
System.out.println("获取当前的时间,不含有日期:"+time);
}
}可以看到当前时间就只包含时间信息，没有日期
通过增加小时、分、秒来计算将来的时间很常见。Java 8除了不变类型和线程安全的好处之外，还提供了更好的plusHours()方法替换add()，并且是兼容的。注意，这些方法返回一个全新的LocalTime实例，由于其不可变性，返回后一定要用变量赋值。
package com.shxt.demo02;
import java.time.LocalTime;
public class Demo07 {
public static void main(String[] args) {
LocalTime time = LocalTime.now();
LocalTime newTime = time.plusHours(3);
System.out.println("三个小时后的时间为:"+newTime);
}
}和上个例子计算3小时以后的时间类似，这个例子会计算一周后的日期。LocalDate日期不包含时间信息，它的plus()方法用来增加天、周、月，ChronoUnit类声明了这些时间单位。由于LocalDate也是不变类型，返回后一定要用变量赋值。
package com.shxt.demo02;
import java.time.LocalDate;
import java.time.temporal.ChronoUnit;
public class Demo08 {
public static void main(String[] args) {
LocalDate today = LocalDate.now();
System.out.println("今天的日期为:"+today);
LocalDate nextWeek = today.plus(1, ChronoUnit.WEEKS);
System.out.println("一周后的日期为:"+nextWeek);
}
}可以看到新日期离当天日期是7天，也就是一周。你可以用同样的方法增加1个月、1年、1小时、1分钟甚至一个世纪，更多选项可以查看Java 8 API中的ChronoUnit类
利用minus()方法计算一年前的日期
package com.shxt.demo02;
import java.time.LocalDate;
import java.time.temporal.ChronoUnit;
public class Demo09 {
public static void main(String[] args) {
LocalDate today = LocalDate.now();
LocalDate previousYear = today.minus(1, ChronoUnit.YEARS);
System.out.println("一年前的日期 : " + previousYear);
LocalDate nextYear = today.plus(1, ChronoUnit.YEARS);
System.out.println("一年后的日期:"+nextYear);
}
}Java 8增加了一个Clock时钟类用于获取当时的时间戳，或当前时区下的日期时间信息。以前用到System.currentTimeInMillis()和TimeZone.getDefault()的地方都可用Clock替换。
package com.shxt.demo02;
import java.time.Clock;
public class Demo10 {
public static void main(String[] args) {
// Returns the current time based on your system clock and set to UTC.
Clock clock = Clock.systemUTC();
System.out.println("Clock : " + clock.millis());
// Returns time based on system clock zone
Clock defaultClock = Clock.systemDefaultZone();
System.out.println("Clock : " + defaultClock.millis());
}
}另一个工作中常见的操作就是如何判断给定的一个日期是大于某天还是小于某天？在Java 8中，LocalDate类有两类方法isBefore()和isAfter()用于比较日期。调用isBefore()方法时，如果给定日期小于当前日期则返回true。
package com.shxt.demo02;
import java.time.LocalDate;
import java.time.temporal.ChronoUnit;
public class Demo11 {
public static void main(String[] args) {
LocalDate today = LocalDate.now();
LocalDate tomorrow = LocalDate.of(2018,2,6);
if(tomorrow.isAfter(today)){
System.out.println("之后的日期:"+tomorrow);
}
LocalDate yesterday = today.minus(1, ChronoUnit.DAYS);
if(yesterday.isBefore(today)){
System.out.println("之前的日期:"+yesterday);
}
}
}Java 8不仅分离了日期和时间，也把时区分离出来了。现在有一系列单独的类如ZoneId来处理特定时区，ZoneDateTime类来表示某时区下的时间。这在Java 8以前都是 GregorianCalendar类来做的。下面这个例子展示了如何把本时区的时间转换成另一个时区的时间。
package com.shxt.demo02;
import java.time.LocalDateTime;
import java.time.ZoneId;
import java.time.ZonedDateTime;
public class Demo12 {
public static void main(String[] args) {
// Date and time with timezone in Java 8
ZoneId america = ZoneId.of("America/New_York");
LocalDateTime localtDateAndTime = LocalDateTime.now();
ZonedDateTime dateAndTimeInNewYork = ZonedDateTime.of(localtDateAndTime, america );
System.out.println("Current date and time in a particular timezone : " + dateAndTimeInNewYork);
}
}与 MonthDay检查重复事件的例子相似，YearMonth是另一个组合类，用于表示信用卡到期日、FD到期日、期货期权到期日等。还可以用这个类得到 当月共有多少天，YearMonth实例的lengthOfMonth()方法可以返回当月的天数，在判断2月有28天还是29天时非常有用。
package com.shxt.demo02;
import java.time.*;
public class Demo13 {
public static void main(String[] args) {
YearMonth currentYearMonth = YearMonth.now();
System.out.printf("Days in month year %s: %d%n", currentYearMonth, currentYearMonth.lengthOfMonth());
YearMonth creditCardExpiry = YearMonth.of(2019, Month.FEBRUARY);
System.out.printf("Your credit card expires on %s %n", creditCardExpiry);
}
}package com.shxt.demo02;
import java.time.LocalDate;
public class Demo14 {
public static void main(String[] args) {
LocalDate today = LocalDate.now();
if(today.isLeapYear()){
System.out.println("This year is Leap year");
}else {
System.out.println("2018 is not a Leap year");
}
}
}有一个常见日期操作是计算两个日期之间的天数、周数或月数。在Java 8中可以用java.time.Period类来做计算。
下面这个例子中，我们计算了当天和将来某一天之间的月数。
package com.shxt.demo02;
import java.time.LocalDate;
import java.time.Period;
public class Demo15 {
public static void main(String[] args) {
LocalDate today = LocalDate.now();
LocalDate java8Release = LocalDate.of(2018, 12, 14);
Period periodToNextJavaRelease = Period.between(today, java8Release);
System.out.println("Months left between today and Java 8 release : "
+ periodToNextJavaRelease.getMonths() );
}
}Instant类有一个静态工厂方法now()会返回当前的时间戳，如下所示：
package com.shxt.demo02;
import java.time.Instant;
public class Demo16 {
public static void main(String[] args) {
Instant timestamp = Instant.now();
System.out.println("What is value of this instant " + timestamp.toEpochMilli());
}
}时间戳信息里同时包含了日期和时间，这和java.util.Date很像。实际上Instant类确实等同于 Java 8之前的Date类，你可以使用Date类和Instant类各自的转换方法互相转换，例如：Date.from(Instant) 将Instant转换成java.util.Date，Date.toInstant()则是将Date类转换成Instant类。
package com.shxt.demo02;
import java.time.LocalDate;
import java.time.format.DateTimeFormatter;
public class Demo17 {
public static void main(String[] args) {
String dayAfterTommorrow = "20180205";
LocalDate formatted = LocalDate.parse(dayAfterTommorrow,
DateTimeFormatter.BASIC_ISO_DATE);
System.out.println(dayAfterTommorrow+" 格式化后的日期为: "+formatted);
}
}package com.shxt.demo02;
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
public class Demo18 {
public static void main(String[] args) {
LocalDateTime date = LocalDateTime.now();
DateTimeFormatter format1 = DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm:ss");
//日期转字符串
String str = date.format(format1);
System.out.println("日期转换为字符串:"+str);
DateTimeFormatter format2 = DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm:ss");
//字符串转日期
LocalDate date2 = LocalDate.parse(str,format2);
System.out.println("日期类型:"+date2);
}
}1.说到数据库事务，人们脑海里自然不自然的就会浮现出事务的四大特性、四大隔离级别、七大传播特性。四大还好说，问题是七大传播特性是哪儿来的？是Spring在当前线程内，处理多个数据库操作方法事务时所做的一种事务应用策略。事务本身并不存在什么传播特性，不要混淆事务本身和Spring的事务应用策略。（当然，找工作面试时，还是可以巧妙的描述传播特性的）
2.一说到事务，人们可能又会想起create、begin、commit、rollback、close、suspend。可实际上，只有commit、rollback是实际存在的，剩下的create、begin、close、suspend都是虚幻的，是业务层或数据库底层应用语意，而非JDBC事务的真实命令。
create（事务创建）：不存在。
begin（事务开始）：姑且认为存在于DB的命令行中，比如Mysql的start transaction命令，以及其他数据库中的begin transaction命令。JDBC中不存在。
close（事务关闭）：不存在。应用程序接口中的close()方法，是为了把connection放回数据库连接池中，供下一次使用，与事务毫无关系。
suspend（事务挂起）：不存在。Spring中事务挂起的含义是，需要新事务时，将现有的connection1保存起来（它还有尚未提交的事务），然后创建connection2，connection2提交、回滚、关闭完毕后，再把connection1取出来，完成提交、回滚、关闭等动作，保存connection1的动作称之为事务挂起。在JDBC中，是根本不存在事务挂起的说法的，也不存在这样的接口方法。
因此，记住事务的三个真实存在的方法，不要被各种事务状态名词所迷惑，它们分别是：conn.setAutoCommit()、conn.commit()、conn.rollback()。
conn.close()含义为关闭一个数据库连接，这已经不再是事务方法了。
public interface Transaction {
Connection getConnection() throws SQLException;
void commit() throws SQLException;
void rollback() throws SQLException;
void close() throws SQLException;
}有了文章开头的分析，当你再次看到close()方法时，千万别再认为是关闭一个事务了，而是关闭一个conn连接，或者是把conn连接放回连接池内。
事务类层次结构图：
JdbcTransaction：单独使用Mybatis时，默认的事务管理实现类，就和它的名字一样，它就是我们常说的JDBC事务的极简封装，和编程使用mysql-connector-java-5.1.38-bin.jar事务驱动没啥差别。其极简封装，仅是让connection支持连接池而已。
ManagedTransaction：含义为托管事务，空壳事务管理器，皮包公司。仅是提醒用户，在其它环境中应用时，把事务托管给其它框架，比如托管给Spring，让Spring去管理事务。
org.apache.ibatis.transaction.jdbc.JdbcTransaction.java部分源码。
@Override
public void close() throws SQLException {
if (connection != null) {
resetAutoCommit();
if (log.isDebugEnabled()) {
log.debug("Closing JDBC Connection [" + connection + "]");
}
connection.close();
}
}面对上面这段代码，我们不禁好奇，connection.close()之前，居然调用了一个resetAutoCommit()，含义为重置autoCommit属性值。connection.close()含义为销毁conn，既然要销毁conn，为何还多此一举的调用一个resetAutoCommit()呢？消失之前多喝口水，真的没有必要。
其实，原因是这样的，connection.close()不意味着真的要销毁conn，而是要把conn放回连接池，供下一次使用，既然还要使用，自然就需要重置AutoCommit属性了。通过生成connection代理类，来实现重回连接池的功能。如果connection是普通的Connection实例，那么代码也是没有问题的，双重支持。
顾名思义，一个生产JdbcTransaction实例，一个生产ManagedTransaction实例。两个毫无实际意义的工厂类，除了new之外，没有其他代码。
<transactionManager type="JDBC" />
mybatis-config.xml配置文件内，可配置事务管理类型。
无论是SqlSession，还是Executor，它们的事务方法，最终都指向了Transaction的事务方法，即都是由Transaction来完成事务提交、回滚的。
配一个简单的时序图。
代码样例：
public static void main(String[] args) {
SqlSession sqlSession = MybatisSqlSessionFactory.openSession();
try {
StudentMapper studentMapper = sqlSession.getMapper(StudentMapper.class);
Student student = new Student();
student.setName("yy");
student.setEmail("email@email.com");
student.setDob(new Date());
student.setPhone(new PhoneNumber("123-2568-8947"));
studentMapper.insertStudent(student);
sqlSession.commit();
} catch (Exception e) {
sqlSession.rollback();
} finally {
sqlSession.close();
}
}注：Executor在执行insertStudent(student)方法时，与事务的提交、回滚、关闭毫无瓜葛（方法内部不会提交、回滚事务），需要像上面的代码一样，手动显示调用commit()、rollback()、close()等方法。
因此，后续在分析到类似insert()、update()等方法内部时，需要忘记事务的存在，不要试图在insert()等方法内部寻找有关事务的任何方法。
1. 一个conn生命周期内，可以存在无数多个事务。
// 执行了connection.setAutoCommit(false)，并返回
SqlSession sqlSession = MybatisSqlSessionFactory.openSession();
try {
StudentMapper studentMapper = sqlSession.getMapper(StudentMapper.class);
Student student = new Student();
student.setName("yy");
student.setEmail("email@email.com");
student.setDob(new Date());
student.setPhone(new PhoneNumber("123-2568-8947"));
studentMapper.insertStudent(student);
// 提交
sqlSession.commit();
studentMapper.insertStudent(student);
// 多次提交
sqlSession.commit();
} catch (Exception e) {
// 回滚，只能回滚当前未提交的事务
sqlSession.rollback();
} finally {
sqlSession.close();
}对于JDBC来说，autoCommit=false时，是自动开启事务的，执行commit()后，该事务结束。以上代码正常情况下，开启了2个事务，向数据库插入了2条数据。JDBC中不存在Hibernate中的session的概念，在JDBC中，insert了几次，数据库就会有几条记录，切勿混淆。而rollback()，只能回滚当前未提交的事务。
2. autoCommit=false，没有执行commit()，仅执行close()，会发生什么？
try {
studentMapper.insertStudent(student);
} finally {
sqlSession.close();
}就像上面这样的代码，没有commit()，固执的程序员总是好奇这样的特例。
insert后，close之前，如果数据库的事务隔离级别是read uncommitted，那么，我们可以在数据库中查询到该条记录。
接着执行sqlSession.close()时，经过SqlSession的判断，决定执行rollback()操作，于是，事务回滚，数据库记录消失。
下面，我们看看org.apache.ibatis.session.defaults.DefaultSqlSession.java中的close()方法源码。
@Override
public void close() {
try {
executor.close(isCommitOrRollbackRequired(false));
dirty = false;
} finally {
ErrorContext.instance().reset();
}
}事务是否回滚，依靠isCommitOrRollbackRequired(false)方法来判断。
private boolean isCommitOrRollbackRequired(boolean force) {
return (!autoCommit && dirty) || force;
}在上面的条件判断中，!autoCommit=true（取反当然是true了），force=false，最终是否回滚事务，只有dirty参数了，dirty含义为是否是脏数据。
@Override
public int insert(String statement, Object parameter) {
return update(statement, parameter);
}
@Override
public int update(String statement, Object parameter) {
try {
dirty = true;
MappedStatement ms = configuration.getMappedStatement(statement);
return executor.update(ms, wrapCollection(parameter));
} catch (Exception e) {
throw ExceptionFactory.wrapException("Error updating database. Cause: " + e, e);
} finally {
ErrorContext.instance().reset();
}
}源码很明确，只要执行update操作，就设置dirty=true。insert、delete最终也是执行update操作。
只有在执行完commit()、rollback()、close()等方法后，才会再次设置dirty=false。
@Override
public void commit(boolean force) {
try {
executor.commit(isCommitOrRollbackRequired(force));
dirty = false;
} catch (Exception e) {
throw ExceptionFactory.wrapException("Error committing transaction. Cause: " + e, e);
} finally {
ErrorContext.instance().reset();
}
}因此，得出结论：autoCommit=false，但是没有手动commit，在sqlSession.close()时，Mybatis会将事务进行rollback()操作，然后才执行conn.close()关闭连接，当然数据最终也就没能持久化到数据库中了。
3. autoCommit=false，没有commit，也没有close，会发生什么？
studentMapper.insertStudent(student);
干脆，就这一句话，即不commit，也不close。
结论：insert后，jvm结束前，如果事务隔离级别是read uncommitted，我们可以查到该条记录。jvm结束后，事务被rollback()，记录消失。通过断点debug方式，你可以看到效果。
这说明JDBC驱动实现，已经Kao虑到这样的特例情况，底层已经有相应的处理机制了。这也超出了我们的探究范围。
但是，一万个屌丝程序员会对你说：Don't do it like this. Go right way。
警告：请按正确的try-catch-finally编程方式处理事务，若不从，本人概不负责后果。
注：无参的openSession()方法，会自动设置autoCommit=false。
总结：Mybatis的JdbcTransaction，和纯粹的Jdbc事务，几乎没有差别，它仅是扩展支持了连接池的connection。
另外，需要明确，无论你是否手动处理了事务，只要是对数据库进行任何update操作（update、delete、insert），都一定是在事务中进行的，这是数据库的设计规范之一。读完本篇文章，是否颠覆了你心中目前对事务的理解呢？
在程序设计中，有很多的“公约”，遵守约定去实现你的代码，会让你避开很多坑，这些公约是前人总结出来的设计规范。
Object类是Java中的万类之祖，其中，equals和hashCode是2个非常重要的方法。
这2个方法总是被人放在一起讨论。最近在看集合框架，为了打基础，就决定把一些细枝末节清理掉。一次性搞清楚！
下面开始剖析。
public boolean equals(Object obj)
Object类中默认的实现方式是 : return this == obj 。那就是说，只有this 和 obj引用同一个对象，才会返回true。
而我们往往需要用equals来判断 2个对象是否等价，而非验证他们的唯一性。这样我们在实现自己的类时，就要重写equals.
按照约定，equals要满足以下规则。
自反性: x.equals(x) 一定是true
对null: x.equals(null) 一定是false
对称性: x.equals(y) 和 y.equals(x)结果一致
传递性: a 和 b equals , b 和 c equals，那么 a 和 c也一定equals。
一致性: 在某个运行时期间，2个对象的状态的改变不会不影响equals的决策结果，那么，在这个运行时期间，无论调用多少次equals，都返回相同的结果。
一个例子
equals编写指导
Test类对象有2个字段，num和data，这2个字段代表了对象的状态，他们也用在equals方法中作为评判的依据。
在第8行，传入的比较对象的引用和this做比较，这样做是为了 save time ，节约执行时间，如果this 和 obj是 对同一个堆对象的引用，那么，他们一定是qeuals 的。
接着，判断obj是不是为null，如果为null，一定不equals，因为既然当前对象this能调用equals方法，那么它一定不是null，非null 和 null当然不等价。
然后，比较2个对象的运行时类，是否为同一个类。不是同一个类，则不equals。getClass返回的是 this 和obj的运行时类的引用。如果他们属于同一个类，则返回的是同一个运行时类的引用。注意，一个类也是一个对象。
1、 有些程序员使用下面的第二种写法替代第一种比较运行时类的写法。应该避免这样做。
它违反了公约中的对称原则。
例如：假设Dog扩展了Aminal类。
这就会导致
仅当Test类没有子类的时候，这样做才能保证是正确的。
3、按照第一种方法实现，那么equals只能比较同一个类的对象，不同类对象永远是false。但这并不是强制要求的。一般我们也很少需要在不同的类之间使用equals。
4、在具体比较对象的字段的时候，对于基本值类型的字段，直接用 == 来比较（注意浮点数的比较，这是一个坑）对于引用类型的字段，你可以调用他们的equals，当然，你也需要处理字段为null 的情况。对于浮点数的比较，我在看Arrays.binarySearch的源代码时，发现了如下对于浮点数的比较的技巧：
5、并不总是要将对象的所有字段来作为equals 的评判依据，那取决于你的业务要求。比如你要做一个家电功率统计系统，如果2个家电的功率一样，那就有足够的依据认为这2个家电对象等价了，至少在你这个业务逻辑背景下是等价的，并不关心他们的价钱啊，品牌啊，大小等其他参数。
6、最后需要注意的是，equals 方法的参数类型是Object，不要写错！
public int hashCode()
这个方法返回对象的散列码，返回值是int类型的散列码。
对象的散列码是为了更好的支持基于哈希机制的Java集合类，例如 Hashtable, HashMap, HashSet 等。
关于hashCode方法，一致的约定是：
重写了euqls方法的对象必须同时重写hashCode()方法。
如果2个对象通过equals调用后返回是true，那么这个2个对象的hashCode方法也必须返回同样的int型散列码
如果2个对象通过equals返回false，他们的hashCode返回的值允许相同。(然而，程序员必须意识到，hashCode返回独一无二的散列码，会让存储这个对象的hashtables更好地工作。)
在上面的例子中，Test类对象有2个字段，num和data，这2个字段代表了对象的状态，他们也用在equals方法中作为评判的依据。那么， 在hashCode方法中，这2个字段也要参与hash值的运算，作为hash运算的中间参数。这点很关键，这是为了遵守：2个对象equals，那么 hashCode一定相同规则。
也是说，参与equals函数的字段，也必须都参与hashCode 的计算。
合乎情理的是：同一个类中的不同对象返回不同的散列码。典型的方式就是根据对象的地址来转换为此对象的散列码，但是这种方式对于Java来说并不是唯一的要求的
的实现方式。通常也不是最好的实现方式。
相比 于 equals公认实现约定，hashCode的公约要求是很容易理解的。有2个重点是hashCode方法必须遵守的。约定的第3点，其实就是第2点的细化，下面我们就来看看对hashCode方法的一致约定要求。
在某个运行时期间，只要对象的（字段的）变化不会影响equals方法的决策结果，那么，在这个期间，无论调用多少次hashCode，都必须返回同一个散列码。
通过equals调用返回true 的2个对象的hashCode一定一样。
通过equasl返回false 的2个对象的散列码不需要不同，也就是他们的hashCode方法的返回值允许出现相同的情况。
总结一句话：等价的(调用equals返回true)对象必须产生相同的散列码。不等价的对象，不要求产生的散列码不相同。
hashCode编写指导
在编写hashCode时，你需要考虑的是，最终的hash是个int值，而不能溢出。不同的对象的hash码应该尽量不同，避免hash冲突。
那么如果做到呢？下面是解决方案。
定义一个int类型的变量 hash，初始化为 7。
接下来让你认为重要的字段（equals中衡量相等的字段）参入散列运，算每一个重要字段都会产生一个hash分量，为最终的hash值做出贡献（影响）
运算方法参考表
最后把所有的分量都总和起来，注意并不是简单的相加。选择一个倍乘的数字31，参与计算。然后不断地递归计算，直到所有的字段都参与了。
mybatis-plus是完全基于mybatis开发的一个增强工具，它的设计理念是在mybatis的基础上只做增强不做改变，为简化开发、提高效率而生，它在mybatis的基础上增加了很多实用性的功能，比如增加了乐观锁插件、字段自动填充功能、分页插件、条件构造器、sql注入器等等，这些在开发过程中都是非常实用的功能，mybatis-plus可谓是站在巨人的肩膀上进行了一系列的创新，我个人极力推荐。下面我会详细地从源码的角度分析mybatis-plus（下文简写成mp）是如何实现sql自动注入的原理。
我们回顾一下mybatis的Mapper的注册与绑定过程，我之前也写过一篇「Mybatis源码分析之Mapper注册与绑定」，在这篇文章中，我详细地讲解了Mapper绑定的最终目的是将xml或者注解上的sql信息与其对应Mapper类注册到MappedStatement中，既然mybatis-plus的设计理念是在mybatis的基础上只做增强不做改变，那么sql注入器必然也是在将我们预先定义好的sql和预先定义好的Mapper注册到MappedStatement中。
现在我将Mapper的注册与绑定过程用时序图再梳理一遍：
解析一下这几个类的作用：
SqlSessionFactoryBean：继承了FactoryBean和InitializingBean，符合spring loc容器bean的基本规范，可在获取该bean时调用getObject()方法到SqlSessionFactory。
XMLMapperBuilder：xml文件解析器，解析Mapper对应的xml文件信息，并将xml文件信息注册到Configuration中。
XMLStatementBuilder：xml节点解析器，用于构建select/insert/update/delete节点信息。
MapperBuilderAssistant：Mapper构建助手，将Mapper节点信息封装成statement添加到MappedStatement中。
MapperRegistry：Mapper注册与绑定类，将Mapper的类信息与MapperProxyFactory绑定。
MapperAnnotationBuilder：Mapper注解解析构建器，这也是为什么mybatis可以直接在Mapper方法添加注解信息就可以不用在xml写sql信息的原因，这个构建器专门用于解析Mapper方法注解信息，并将这些信息封装成statement添加到MappedStatement中。
从时序图可知，Configuration配置类存储了所有Mapper注册与绑定的信息，然后创建SqlSessionFactory时再将Configuration注入进去，最后经过SqlSessionFactory创建出来的SqlSession会话，就可以根据Configuration信息进行数据库交互，而MapperProxyFactory会为每个Mapper创建一个MapperProxy代理类，MapperProxy包含了Mapper操作SqlSession所有的细节，因此我们就可以直接使用Mapper的方法就可以跟SqlSession进行交互。
源码分析
从Mapper的注册与绑定过程的时序图看，要想将sql注入器无缝链接地添加到mybatis里面，那就得从Mapper注册步骤添加，果然，mp很鸡贼地继承了MapperRegistry这个类然后重写了addMapper方法：
方法中将MapperAnnotationBuilder替换成了自家的MybatisMapperAnnotationBuilder，在这里特别说明一下，mp为了不更改mybatis原有的逻辑，会用继承或者直接粗暴地将其复制过来，然后在原有的类名上加上前缀“Mybatis”。
sql注入器就是从这个方法里面添加上去的，首先判断Mapper是否是BaseMapper的超类或者超接口，BaseMapper是mp的基础Mapper，里面定义了很多默认的基础方法，意味着我们一旦使用上mp，通过sql注入器，很多基础的数据库操作都可以直接继承BaseMapper实现了，开发效率爆棚有木有！
GlobalConfiguration是mp的全局缓存类，用于存放mp自带的一些功能，很明显，sql注入器就存放在GlobalConfiguration中。
这个方法是先从全局缓存类中获取自定义的sql注入器，如果在GlobalConfiguration中没有找到自定义sql注入器，就会设置一个mp默认的sql注入器AutoSqlInjector。
sql注入器接口：
所有自定义的sql注入器都需要实现ISqlInjector接口，mp已经为我们默认实现了一些基础的注入器：
其中AutoSqlInjector提供了最基本的sql注入，以及一些通用的sql注入与拼装的逻辑，LogicSqlInjector在AutoSqlInjector的基础上复写了删除逻辑，因为我们的数据库的数据删除实质上是软删除，并不是真正的删除。
该方法是sql注入器的入口，在入口处添加了注入过后不再注入的判断功能。
注入之前先将Mapper类提取泛型模型，因为继承BaseMapper需要将Mapper对应的model添加到泛型里面，这时候我们需要将其提取出来，提取出来后还需要将其初始化成一个TableInfo对象，TableInfo存储了数据库对应的model所有的信息，包括表主键ID类型、表名称、表字段信息列表等等信息，这些信息通过反射获取。
所有需要注入的sql都是通过该方法进行调用，AutoSqlInjector还提供了一个inject方法，自定义sql注入器时，继承AutoSqlInjector，实现该方法就行了。
我随机选择一个删除sql的注入，其它sql注入都是类似这么写，SqlMethod是一个枚举类，里面存储了所有自动注入的sql与方法名，如果是批量操作，SqlMethod的定义的sql语句在添加批量操作的语句。再根据table和sql信息创建一个SqlSource对象。
sql注入器的最终操作，这里会判断MappedStatement是否存在，这个判断是有原因的，它会防止重复注入，如果你的Mapper方法已经在Mybatis的逻辑里面注册了，mp不会再次注入。最后调用MapperBuilderAssistant助手类的addMappedStatement方法执行注册操作。
本篇文章讲解如何在ssm（spring、springmvc、mybatis）结构的程序上集成sharding-jdbc（版本为2.0.3）进行分库分表；
假设分库分表行为如下：
将auth_user表分到4个库（user_0~user_3）中；
其他表不进行分库分表，保留在default_db库中；
1. POM配置
以spring配置文件为例，新增如下POM配置：
2 . 配置数据源
spring-datasource.xml配置所有需要的数据源如下–auth_user分库分表后需要的4个库user_0~user_3，以及不分库分表的默认库default_db：
properties配置文件内容如下：
3. 集成sharding数据源
spring-sharding.xml配置如下：
说明：spring-sharding.xml配置的分库分表规则：auth_user表分到id为sj_ds_${0..3}的四个库中，表名保持不变；其他表在id为sj_ds_default库中，不分库也不分表；集成sharding-jdbc的核心就是将SqlSessionFactoryBean需要的dataSource属性修改为shardingDataSource，把数据源交给sharding-jdbc处理；
另外，通过对比这里和sharding-jdbc1.5.4.1版本的配置请戳链接：https://www.jianshu.com/p/602e24845ed3，差异还是比较大，大概提现在如下一些地方：
namespace由rdb改为sharding；
默认数据库策略和默认表策略被设置为“节点的属性，分别是default-database-strategy-ref和default-table-strategy-ref；
默认数据源被设置为“节点的属性，即default-data-source-name；
“一些属性变更，例如：actual-tables改为actual-data-nodes，database-strategy改为database-strategy-ref；
分库逻辑AuthUserDatabaseShardingAlgorithm的代码很简单，源码如下：
这段代码参考sharding-jdbc源码中PreciseShardingAlgorithm.java接口的实现即可，例如PreciseModuloDatabaseShardingAlgorithm.java；这里和sharding-jdbc1.5.4.1版本的差异也比较大，sharding-jdbc1.5.4.1对于分库或者分表sharding算法实现的接口是不一样的，sharding-jdbc2.0.3将两者合二为一，且只有一个方法，即doSharding();
4. 注意事项
无法识别sharding-jdbc分库分表规则inline-expression问题，例如：
“
根本原因：
根本原因是spring把${}当做占位符，${0..3}这种表达式，spring会尝试去properties文件中找key为0..3的属性。但是这里是sharding-jdbc分库分表规则的inline表达式，需要spring忽略这种行为。否则会抛出异常:
java.lang.IllegalArgumentException: Could not resolve placeholder ‘0..3’ in value “sj_ds_${0..3}.auth_user”
解决办法：
配置: 或者:
5. Main测试
Main.java用来测试分库分表是否OK，其源码如下：
Array类的使用
java.lang.Array是对Java反射包中数组操作的一个类。JavaSE8的文档中对Array的描述是这样说的：
The Array class provides static methods to dynamically create and access Java arrays.
Array类提供静态方法来动态创建和访问Java数组。访问不难理解，动态创建可以细看一下。
让我们先看看java.util.Arrays
注意是Arrays，相信有些小伙伴已经用过很多次这个工具类了，提供了很多对数组操作的方法方便我们使用。
上面说了java.lang.Array是提供给我们静态方法来动态创建和访问数组。让我们来看看Arrays中的copyOf方式是怎么来动态操作数组的吧。
copyOf是拿来干嘛的呢？Arrays主要提供这个方法来给已经填满的数组来拓展数组大小的。
你可以这样用
不知道大家有没有注意到，这个方法是个泛型的返回结果。它的第一个参数是原始数组，第二个参数为新的长度，返回的是调用了另一个重载的copyOf方法，让我们来看看这个重载的copyOf方法吧。
里面的调用不难理解，就是如果传进来的original对象数组的Class和Object[]的Class相等那就直接new Object[]如果不相等就调用java.lang.reflect.Array中的newInstance方法进行创建新数组，后面调用的是System.arraycopy方法的作用源码中的注释是：Copies an array from the specified source array, beginning at the specified position, to the specified position of the destination array. 意思是：从指定的数组的制定位置开始复制到目标数组的指定位置。
为什么要用反射实现数组的扩展
我们来看一下不用反射实现的"copyOf"
如果没有上面那个Arrays的copyOf方法可能很多人会直接潇潇洒洒写出如上代码。不过有没有想过一个问题，他能不能转型成对应的你想用的类？这样说，一个MyObject[]类转成Object[]，然后再转回来是可以的，但是从一开始就是Object[]的数组是不能转成MyObject[]，这样做会抛出ClassCastException异常，这是因为这个数组是用new Object[length]创建的，Java数组在创建的时候回记住每个元素的类型，就是在new的时候的类型。
那么怎样我们才可以强转呢？看如下代码
看了上面代码，有的小伙伴会有疑问，为什么要用object接收数组对象，这是因为基本数据类型的数组不能传给对象数组，但是可以转成对象
访问数组内的对象
Array类提供了一些方法可以供我们使用
完整代码如下
在 web 开发中，我们经常会用到 Session 来保存会话信息，包括用户信息、权限信息，等等。在这篇文章中，我们将分析 tomcat 容器是如何创建 session、销毁 session，又是如何对 HttpSessionListener 进行事件通知
tomcat session 设计分析
tomcat session 组件图如下所示，其中 Context 对应一个 webapp 应用，每个 webapp 有多个 HttpSessionListener， 并且每个应用的 session 是独立管理的，而 session 的创建、销毁由 Manager 组件完成，它内部维护了 N 个 Session 实例对象。在前面的文章中，我们分析了 Context 组件，它的默认实现是 StandardContext，它与 Manager 是一对一的关系，Manager 创建、销毁会话时，需要借助 StandardContext 获取 HttpSessionListener 列表并进行事件通知，而 StandardContext 的后台线程会对 Manager 进行过期 Session 的清理工作
org.apache.catalina.Manager 接口的主要方法如下所示，它提供了 Context、org.apache.catalina.SessionIdGenerator的 getter/setter 接口，以及创建、添加、移除、查找、遍历 Session 的 API 接口，此外还提供了 Session 持久化的接口（load/unload） 用于加载/卸载会话信息，当然持久化要看不同的实现类
tomcat8.5 提供了 4 种实现，默认使用 StandardManager，tomcat 还提供了集群会话的解决方案，但是在实际项目中很少运用，关于 Manager 的详细配置信息请参考 tomcat 官方文档
StandardManager：Manager 默认实现，在内存中管理 session，宕机将导致 session 丢失；但是当调用 Lifecycle 的 start/stop 接口时，将采用 jdk 序列化保存 Session 信息，因此当 tomcat 发现某个应用的文件有变更进行 reload 操作时，这种情况下不会丢失 Session 信息
DeltaManager：增量 Session 管理器，用于Tomcat集群的会话管理器，某个节点变更 Session 信息都会同步到集群中的所有节点，这样可以保证 Session 信息的实时性，但是这样会带来较大的网络开销
BackupManager：用于 Tomcat 集群的会话管理器，与DeltaManager不同的是，某个节点变更 Session 信息的改变只会同步给集群中的另一个 backup 节点
PersistentManager：当会话长时间空闲时，将会把 Session 信息写入磁盘，从而限制内存中的活动会话数量；此外，它还支持容错，会定期将内存中的 Session 信息备份到磁盘
Session 相关的类图如下所示，StandardSession 同时实现了 javax.servlet.http.HttpSession、org.apache.catalina.Session 接口，并且对外提供的是 StandardSessionFacade 外观类，保证了 StandardSession 的安全，避免开发人员调用其内部方法进行不当操作。而 org.apache.catalina.connector.Request 实现了 javax.servlet.http.HttpServletRequest 接口，它持有 StandardSession 的引用，对外也是暴露 RequestFacade 外观类。而 StandardManager 内部维护了其创建的 StandardSession，是一对多的关系，并且持有 StandardContext 的引用，而 StandardContext 内部注册了 webapp 所有的 HttpSessionListener 实例。
创建Session
我们以 HttpServletRequest#getSession() 作为切入点，对 Session 的创建过程进行分析
整个流程图如下图所示(查看原图)：
tomcat 创建 session 的流程如上图所示，我们的应用程序拿到的 HttpServletRequest 是 org.apache.catalina.connector.RequestFacade(除非某些 Filter 进行了特殊处理)，它是 org.apache.catalina.connector.Request 的门面模式。首先，会判断 Request 对象中是否存在 Session，如果存在并且未失效则直接返回，因为在 tomcat 中 Request 对象是被重复利用的，只会替换部分组件，所以会进行这步判断。此时，如果不存在 Session，则尝试根据 requestedSessionId 查找 Session，而该 requestedSessionId 会在 HTTP Connector 中进行赋值（如果存在的话），如果存在 Session 的话则直接返回，如果不存在的话，则创建新的 Session，并且把 sessionId 添加到 Cookie 中，后续的请求便会携带该 Cookie，这样便可以根据 Cookie 中的sessionId 找到原来创建的 Session 了
在上面的过程中，Session 的查找、创建都是由 Manager 完成的，下面我们分析下 StandardManager 创建 Session 的具体逻辑。首先，我们来看下 StandardManager 的类图，它也是个 Lifecycle 组件，并且 ManagerBase 实现了主要的逻辑。
整个创建 Session 的过程比较简单，就是实例化 StandardSession 对象并设置其基本属性，以及生成唯一的 sessionId，其次就是记录创建时间，关键代码如下所示：
在 tomcat 中是可以限制 session 数量的，如果需要限制，请指定 Manager 的 maxActiveSessions 参数，默认不做限制，不建议进行设置，但是如果存在恶意攻击，每次请求不携带 Cookie 就有可能会频繁创建 Session，导致 Session 对象爆满最终出现 OOM。另外 sessionId 采用随机算法生成，并且每次生成都会判断当前是否已经存在该 id，从而避免 sessionId 重复。而 StandardManager 是使用 ConcurrentHashMap 存储 session 对象的，sessionId 作为 key，org.apache.catalina.Session 作为 value。此外，值得注意的是 StandardManager 创建的是 tomcat 的 org.apache.catalina.session.StandardSession，同时他也实现了 servlet 的 HttpSession，但是为了安全起见，tomcat 并不会把这个 StandardSession 直接交给应用程序，因此需要调用 org.apache.catalina.Session#getSession() 获取 HttpSession。
我们再来看看 StandardSession 的内部结构
attributes：使用 ConcurrentHashMap 解决多线程读写的并发问题
creationTime：Session 的创建时间
expiring：用于标识 Session 是否过期
expiring：用于标识 Session 是否过期
lastAccessedTime：上一次访问的时间，用于计算 Session 的过期时间
maxInactiveInterval：Session 的最大存活时间，如果超过这个时间没有请求，Session 就会被清理、
listeners：这是 tomcat 的 SessionListener，并不是 servlet 的 HttpSessionListener
facade：HttpSession 的外观模式，应用程序拿到的是该对象
Session清理
Background 线程
前面我们分析了 Session 的创建过程，而 Session 会话是有时效性的，下面我们来看下 tomcat 是如何进行失效检查的。在分析之前，我们先回顾下 Container 容器的 Background 线程。
tomcat 所有容器组件，都是继承至 ContainerBase 的，包括 StandardEngine、StandardHost、StandardContext、StandardWrapper，而 ContainerBase 在启动的时候，如果 backgroundProcessorDelay 参数大于 0 则会开启 ContainerBackgroundProcessor 后台线程，调用自己以及子容器的 backgroundProcess 进行一些后台逻辑的处理，和 Lifecycle 一样，这个动作是具有传递性的，也就是说子容器还会把这个动作传递给自己的子容器，如下图所示，其中父容器会遍历所有的子容器并调用其 backgroundProcess 方法，而 StandardContext 重写了该方法，它会调用 StandardManager#backgroundProcess() 进而完成 Session 的清理工作。看到这里，不得不感慨 tomcat 的责任
关键代码如下所示：
Session 检查
backgroundProcessorDelay 参数默认值为 -1，单位为秒，即默认不启用后台线程，而 tomcat 的 Container 容器需要开启线程处理一些后台任务，比如监听 jsp 变更、tomcat 配置变动、Session 过期等等，因此 StandardEngine 在构造方法中便将 backgroundProcessorDelay 参数设为 10（当然可以在 server.xml 中指定该参数），即每隔 10s 执行一次。那么这个线程怎么控制生命周期呢？我们注意到 ContainerBase 有个 threadDone 变量，用 volatile 修饰，如果调用 Container 容器的 stop 方法该值便会赋值为 false，那么该后台线程也会退出循环，从而结束生命周期。另外，有个地方需要注意下，父容器在处理子容器的后台任务时，需要判断子容器的 backgroundProcessorDelay 值，只有当其小于等于 0 才进行处理，因为如果该值大于0，子容器自己会开启线程自行处理，这时候父容器就不需要再做处理了
前面分析了容器的后台线程是如何调度的，下面我们重点来看看 webapp 这一层，以及 StandardManager 是如何清理过期会话的。StandardContext 重写了 backgroundProcess 方法，除了对子容器进行处理之外，还会对一些缓存信息进行清理，关键代码如下所示：
StandardContext 重写了 backgroundProcess 方法，在调用子容器的后台任务之前，还会调用 Loader、Manager、WebResourceRoot、InstanceManager 的后台任务，这里我们只关心 Manager 的后台任务。弄清楚了 StandardManager 的来龙去脉之后，我们接下来分析下具体的逻辑。
StandardManager 继承至 ManagerBase，它实现了主要的逻辑，关于 Session 清理的代码如下所示。backgroundProcess 默认是每隔10s调用一次，但是在 ManagerBase 做了取模处理，默认情况下是 60s 进行一次 Session 清理。tomcat 对 Session 的清理并没有引入时间轮，因为对 Session 的时效性要求没有那么精确，而且除了通知 SessionListener。
IoC 全称为 Inversion of Control，翻译为 “控制反转”，它还有一个别名为 DI（Dependency Injection）,即依赖注入。
如何理解“控制反转”好呢？理解好它的关键在于我们需要回答如下四个问题：
1.谁控制谁
2.控制什么
3.为何是反转
4.哪些方面反转了
在回答这四个问题之前，我们先看 IOC 的定义：
所谓 IOC ，就是由 Spring IOC 容器来负责对象的生命周期和对象之间的关系
上面这句话是整个 IoC 理论的核心。如何来理解这句话？我们引用一个例子来走阐述（看完该例子上面四个问题也就不是问题了）。
已找女朋友为例（对于程序猿来说这个值得探究的问题）。一般情况下我们是如何来找女朋友的呢？首先我们需要根据自己的需求（漂亮、身材好、性格好）找一个妹子，然后到处打听她的兴趣爱好、微信、电话号码，然后各种投其所好送其所要，最后追到手。如下
这就是我们通常做事的方式，如果我们需要某个对象，一般都是采用这种直接创建的方式(new BeautifulGirl())，这个过程复杂而又繁琐，而且我们必须要面对每个环节，同时使用完成之后我们还要负责销毁它，在这种情况下我们的对象与它所依赖的对象耦合在一起。
其实我们需要思考一个问题？我们每次用到自己依赖的对象真的需要自己去创建吗？我们知道，我们依赖对象其实并不是依赖该对象本身，而是依赖它所提供的服务，只要在我们需要它的时候，它能够及时提供服务即可，至于它是我们主动去创建的还是别人送给我们的，其实并不是那么重要。再说了，相比于自己千辛万苦去创建它还要管理、善后而言，直接有人送过来是不是显得更加好呢？
这个给我们送东西的“人” 就是 IoC，在上面的例子中，它就相当于一个婚介公司，作为一个婚介公司它管理着很多男男女女的资料，当我们需要一个女朋友的时候，直接跟婚介公司提出我们的需求，婚介公司则会根据我们的需求提供一个妹子给我们，我们只需要负责谈恋爱，生猴子就行了。你看，这样是不是很简单明了。
诚然，作为婚介公司的 IoC 帮我们省略了找女朋友的繁杂过程，将原来的主动寻找变成了现在的被动接受（符合我们的要求），更加简洁轻便。你想啊，原来你还得鞍马前后，各种巴结，什么东西都需要自己去亲力亲为，现在好了，直接有人把现成的送过来，多么美妙的事情啊。所以，简单点说，IoC 的理念就是让别人为你服务，如下图
在没有引入 IoC 的时候，被注入的对象直接依赖于被依赖的对象，有了 IoC 后，两者及其他们的关系都是通过 Ioc Service Provider 来统一管理维护的。被注入的对象需要什么，直接跟 IoC Service Provider 打声招呼，后者就会把相应的被依赖对象注入到被注入的对象中，从而达到 IOC Service Provider 为被注入对象服务的目的。所以 IoC 就是这么简单！原来是需要什么东西自己去拿，现在是需要什么东西让别人（IOC Service Provider）送过来
现在在看上面那四个问题，答案就显得非常明显了:
谁控制谁：在传统的开发模式下，我们都是采用直接 new 一个对象的方式来创建对象，也就是说你依赖的对象直接由你自己控制，但是有了 IOC 容器后，则直接由 IoC 容器来控制。所以“谁控制谁”，当然是 IoC 容器控制对象。
控制什么：控制对象。
为何是反转：没有 IoC 的时候我们都是在自己对象中主动去创建被依赖的对象，这是正转。但是有了 IoC 后，所依赖的对象直接由 IoC 容器创建后注入到被注入的对象中，依赖的对象由原来的主动获取变成被动接受，所以是反转。
哪些方面反转了：所依赖对象的获取被反转了。
妹子有了，但是如何拥有妹子呢？这也是一门学问。
可能你比较牛逼，刚刚出生的时候就指腹为婚了。
大多数情况我们还是会考虑自己想要什么样的妹子，所以还是需要向婚介公司打招呼的。
还有一种情况就是，你根本就不知道自己想要什么样的妹子，直接跟婚介公司说，我就要一个这样的妹子。
所以，IOC Service Provider 为被注入对象提供被依赖对象也有如下几种方式：构造方法注入、stter方法注入、接口注入。
构造器注入
构造器注入，顾名思义就是被注入的对象通过在其构造方法中声明依赖对象的参数列表，让外部知道它需要哪些依赖对象。
构造器注入方式比较直观，对象构造完毕后就可以直接使用，这就好比你出生你家里就给你指定了你媳妇。
setter 方法注入
对于 JavaBean 对象而言，我们一般都是通过 getter 和 setter 方法来访问和设置对象的属性。所以，当前对象只需要为其所依赖的对象提供相对应的 setter 方法，就可以通过该方法将相应的依赖对象设置到被注入对象中。如下：
相比于构造器注入，setter 方式注入会显得比较宽松灵活些，它可以在任何时候进行注入（当然是在使用依赖对象之前），这就好比你可以先把自己想要的妹子想好了，然后再跟婚介公司打招呼，你可以要林志玲款式的，赵丽颖款式的，甚至凤姐哪款的，随意性较强。
接口方式注入
接口方式注入显得比较霸道，因为它需要被依赖的对象实现不必要的接口，带有侵入性。一般都不推荐这种方式。
各个组件
该图为 ClassPathXmlApplicationContext 的类继承体系结构，虽然只有一部分，但是它基本上包含了 IOC 体系中大部分的核心类和接口。
下面我们就针对这个图进行简单的拆分和补充说明。
Resource体系
Resource，对资源的抽象，它的每一个实现类都代表了一种资源的访问策略，如ClasspathResource 、 URLResource ，FileSystemResource 等。
有了资源，就应该有资源加载，Spring 利用 ResourceLoader 来进行统一资源加载，类图如下：
BeanFactory 体系
BeanFactory 是一个非常纯粹的 bean 容器，它是 IOC 必备的数据结构，其中 BeanDefinition 是她的基本结构，它内部维护着一个 BeanDefinition map ，并可根据 BeanDefinition 的描述进行 bean 的创建和管理。
BeanFacoty 有三个直接子类 ListableBeanFactory、HierarchicalBeanFactory 和 AutowireCapableBeanFactory，DefaultListableBeanFactory 为最终默认实现，它实现了所有接口。
Beandefinition 体系
BeanDefinition 用来描述 Spring 中的 Bean 对象。
BeandefinitionReader体系
BeanDefinitionReader 的作用是读取 Spring 的配置文件的内容，并将其转换成 Ioc 容器内部的数据结构：BeanDefinition。
ApplicationContext体系
这个就是大名鼎鼎的 Spring 容器，它叫做应用上下文，与我们应用息息相关，她继承 BeanFactory，所以它是 BeanFactory 的扩展升级版，如果BeanFactory 是屌丝的话，那么 ApplicationContext 则是名副其实的高富帅。由于 ApplicationContext 的结构就决定了它与 BeanFactory 的不同，其主要区别有：
继承 MessageSource，提供国际化的标准访问策略。
继承 ApplicationEventPublisher ，提供强大的事件机制。
扩展 ResourceLoader，可以用来加载多个 Resource，可以灵活访问不同的资源。
对 Web 应用的支持。
上面五个体系可以说是 Spring IoC 中最核心的部分
千呼万唤，JDK11 于 2018-09-25 正式发布！你是不是和笔者一样还在使用JDK8 呢？甚至有些开发者还在使用 JDK7！没关系，让我们先一睹 JDK11 的风采。
JDK11发布计划
2018/06/28 Rampdown Phase One (fork from main line)
2018/07/19 All Tests Run
2018/07/26 Rampdown Phase Two
2018/08/16 Initial Release Candidate
2018/08/30 Final Release Candidate
2018/09/25 General Availability
JDK11特性一览
181: Nest-Based Access Control
309: Dynamic Class-File Constants
315: Improve Aarch64 Intrinsics
318: Epsilon: A No-Op Garbage Collector
320: Remove the Java EE and CORBA Modules
321: HTTP Client (Standard)
323: Local-Variable Syntax for Lambda Parameters
324: Key Agreement with Curve25519 and Curve448
327: Unicode 10
328: Flight Recorder
329: ChaCha20 and Poly1305 Cryptographic Algorithms
330: Launch Single-File Source-Code Programs
331: Low-Overhead Heap Profiling
332: Transport Layer Security (TLS) 1.3
333: ZGC: A Scalable Low-Latency Garbage Collector
(Experimental)
335: Deprecate the Nashorn JavaScript Engine
336: Deprecate the Pack200 Tools and API
特性详解
接下来对每个特性进行详细解读。
JEP 318: Epsilon: A No-Op Garbage Collector
JDK 上对这个特性的描述是：开发一个处理内存分配但不实现任何实际内存回收机制的 GC，一旦可用堆内存用完，JVM 就会退出。
如果有 System.gc() 的调用，实际上什么也不会发生（这种场景下和 -XX:+DisableExplicitGC 效果一样），因为没有内存回收，这个实现可能会警告用户尝试强制 GC 是徒劳。
用法非常简单：-XX:+UseEpsilonGC。
动机
提供完全被动的 GC 实现，具有有限的分配限制和尽可能低的延迟开销，但代价是内存占用和内存吞吐量。
众所周知，Java 实现可广泛选择高度可配置的 GC 实现。 各种可用的收集器最终满足不同的需求，即使它们的可配置性使它们的功能相交。 有时更容易维护单独的实现，而不是在现有 GC 实现上堆积另一个配置选项。
它的主要用途如下：
性能测试（它可以帮助过滤掉GC引起的性能假象）；
内存压力测试（例如，知道测试用例应该分配不超过 1 GB 的内存，我们可以使用 -Xmx1g 配置 -XX:+UseEpsilonGC ，如果违反了该约束，则会 heap dump 并崩溃）；
非常短的 JOB 任务（对于这种任务，接受 GC 清理堆那都是浪费空间）；
VM接口测试；
Last-drop 延迟&吞吐改进；
JEP 320: Remove the Java EE and CORBA Modules
Java EE 和 CORBA 两个模块在 JDK9 中已经标记”deprecated“，在JDK11 中正式移除。JDK 中 deprecated 的意思是在不建议使用，在未来的 release 版本会被删除。
动机
JavaEE 由 4 部分组成：
JAX-WS (Java API for XML-Based Web Services),
JAXB (Java Architecture for XML Binding)
JAF (the JavaBeans Activation Framework)
Common Annotations.
但是这个特性和 JavaSE 关系不大。并且 JavaEE 被维护在 Github（https://github.com/javaee）中，版本同步造成维护困难。最后，JavaEE 可以单独引用，maven 中心仓库也提供了 JavaEE（http://mvnrepository.com/artifact/javax/javaee-api/8.0），所以没必要把 JavaEE 包含到 JavaSE 中。
至于 CORBA ，使用 Java 中的 CORBA 开发程序没有太大的兴趣。因此，在JavaEE 就把 CORBA 标记为 “Proposed Optional” ，这就表明将来可能会放弃对这些技术的必要支持。
JEP 321: HTTP Client (Standard)
将 JDK9 引进并孵化的 HTTP 客户端 API 作为标准，即 HTTP/2 Client。它定义了一个全新的实现了 HTTP/2 和 WebSocket 的 HTTP 客户端 API，并且可以取代 HttpURLConnection。
动机
已经存在的 HttpURLConnection 有如下问题:
在设计时考虑了多种协议，但是现在几乎所有协议现已不存在。
API 早于 HTTP/1.1 并且太抽象；
使用很不友好；
只能以阻塞模式工作；
非常难维护；
JEP 323: Local-Variable Syntax for Lambda Parameters
在声明隐式类型的lambda表达式的形参时允许使用var。
动机
lamdba 表达式可能是隐式类型的，它形参的所有类型全部靠推到出来的。隐式类型 lambda 表达式如下：
Java SE 10让隐式类型变量可用于本地变量:
为了和本地变量保持一致，我们希望允许 var 作为隐式类型 lambda 表达式的形参：
统一格式的一个好处就是 modifiers 和 notably 注解能被加在本地变量和 lambda 表达式的形参上，并且不会丢失简洁性：
JEP 324: Key Agreement with Curve25519 and Curve448
用 RFC 7748 中描述到的 Curve25519 和 Curve448 实现秘钥协议。 RFC 7748 定义的秘钥协商方案更高效，更安全。这个 JEP 的主要目标就是为这个标准定义 API 和实现。
动机
密码学要求使用 Curve25519 和 Curve448 是因为它们的安全性和性能。JDK 会增加两个新的接口 XECPublicKey 和 XECPrivateKey，示例代码如下：
JEP 327: Unicode 10
更新平台 API 支持 Unicode 10.0版本（Unicode 10.0 概述：Unicode 10.0 增加了 8518 个字符, 总计达到了 136,690 个字符. 并且增加了 4 个脚本, 总结 139 个脚本, 同时还有 56 个新的 emoji 表情符号。
动机
Unicode 是一个不断进化的工业标准，因此必须不断保持 Java 和 Unicode 最新版本同步。
JEP 328: Flight Recorder
提供一个低开销的，为了排错Java应用问题，以及JVM问题的数据收集框架，希望达到的目标如下：
提供用于生产和消费数据作为事件的API；
提供缓存机制和二进制数据格式；
允许事件配置和事件过滤；
提供OS，JVM和JDK库的事件；
动机
排错，监控，性能分析是整个开发生命周期必不可少的一部分，但是某些问题只会在大量真实数据压力下才会发生在生产环境。
Flight Recorder记录源自应用程序，JVM和OS的事件。 事件存储在一个文件中，该文件可以附加到错误报告中并由支持工程师进行检查，允许事后分析导致问题的时期内的问题。工具可以使用API从记录文件中提取信息。
JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms
实现RFC 7539中指定的 ChaCha20 和 ChaCha20-Poly1305 两种加密算法。
动机
唯一一个其他广泛采用的RC4长期以来一直被认为是不安全的，业界一致认为当下ChaCha20-Poly1305是安全的。
JEP 330: Launch Single-File Source-Code Programs
增强Java启动器支持运行单个Java源代码文件的程序。
动机
单文件程序是指整个程序只有一个源码文件，通常是早期学习Java阶段，或者写一个小型工具类。以HelloWorld.java为例，运行它之前需要先编译。我们希望Java启动器能直接运行这个源码级的程序：
等价于：
等价于：
到JDK10为止，Java启动器能以三种方式运行：
启动一个class文件；
启动一个JAR中的main方法类；
启动一个模块中的main方法类；
JDK11再加一个，即第四种方式：启动一个源文件申明的类。
JEP 331: Low-Overhead Heap Profiling
提供一种低开销的Java堆分配采样方法，得到堆分配的Java对象信息，可通过JVMTI访问。希望达到的目标如下：
足够低的开销，可以默认且一直开启；
能通过定义好的程序接口访问；
能采样所有分配；
能给出生存和死亡的Java对象信息；
动机
对用户来说，了解它们堆里的内存是很重要的需求。目前有一些已经开发的工具，允许用户窥探它们的堆，比如：Java Flight Recorder, jmap, YourKit, 以及VisualVM tools.。但是这工具都有一个很大的缺点：无法得到对象的分配位置。headp dump以及heap histo都没有这个信息，但是这个信息对于调试内存问题至关重要。因为它能告诉开发者，他们的代码发生（尤其是坏的）分配的确切位置。
JEP 332: Transport Layer Security (TLS) 1.3
实现TLS协议1.3版本。（TLS允许客户端和服务端通过互联网以一种防止窃听，篡改以及消息伪造的方式进行通信）。
动机
TLS 1.3是TLS协议的重大改进，与以前的版本相比，它提供了显着的安全性和性能改进。其他供应商的几个早期实现已经可用。我们需要支持TLS 1.3以保持竞争力并与最新标准保持同步。这个特性的实现动机和Unicode 10一样，也是紧跟历史潮流。
JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
ZGC：这应该是JDK11最为瞩目的特性，没有之一。但是后面带了Experimental，说明还不建议用到生产环境。看看官方对这个特性的目标描述：
GC暂停时间不会超过10ms；
即能处理几百兆小堆，也能处理几个T的大堆（OMG）；
和G1相比，应用吞吐能力不会下降超过15%；
为未来的GC功能和利用colord指针以及Load barriers优化奠定基础；
初始只支持64位系统；
动机
GC是Java主要优势之一。然而，当GC停顿太长，就会开始影响应用的响应时间。消除或者减少GC停顿时长，Java将对更广泛的应用场景是一个更有吸引力的平台。此外，现代系统中可用内存不断增长， 用户和程序员希望JVM能够以高效的方式充分利用这些内存，并且无需长时间的GC暂停时间。
ZGC一个并发，基于region，压缩型的垃圾收集器，只有root扫描阶段会STW，因此GC停顿时间不会随着堆的增长和存活对象的增长而变长。
ZGC和G1停顿时间比较：
用法：-XX:+UnlockExperimentalVMOptions -XX:+UseZGC，因为ZGC还处于实验阶段，所以需要通过JVM参数UnlockExperimentalVMOptions 来解锁这个特性。
Java的基类Object提供了一些方法，其中equals()方法用于判断两个对象是否相等，hashCode()方法用于计算对象的哈希码。equals()和hashCode()都不是final方法，都可以被重写(overwrite)。
本文介绍了2种方法在使用和重写时，一些需要注意的问题。
目录
一、equals()方法
二、hashCode()方法
1、Object的hashCode()
2、hashCode()的作用
三、String中equals()和hashCode()的实现
四、如何重写hashCode()
1、重写hashcode()的原则
2、hashCode()重写方法
一、equals()方法
Object类中equals()方法实现如下：
虽然我们在定义类时，可以重写equals()方法，但是有一些注意事项；JDK中说明了实现equals()方法应该遵守的约定：通过该实现可以看出，Object类的实现采用了区分度最高的算法，即只要两个对象不是同一个对象，那么equals()一定返回false。
（1）自反性：x.equals(x)必须返回true。
（2）对称性：x.equals(y)与y.equals(x)的返回值必须相等。
（3）传递性：x.equals(y)为true，y.equals(z)也为true，那么x.equals(z)必须为true。
（4）一致性：如果对象x和y在equals()中使用的信息都没有改变，那么x.equals(y)值始终不变。
（5）非null：x不是null，y为null，则x.equals(y)必须为false。
二、hashCode()方法
1、Object的hashCode()
Object类中hashCode()方法的声明如下：
与equals()方法类似，hashCode()方法可以被重写。JDK中对hashCode()方法的作用，以及实现时的注意事项做了说明：可以看出，hashCode()是一个native方法，而且返回值类型是整形；实际上，该native方法将对象在内存中的地址作为哈希码返回，可以保证不同对象的返回值不同。
（1）hashCode()在哈希表中起作用，如java.util.HashMap。
（2）如果对象在equals()中使用的信息都没有改变，那么hashCode()值始终不变。
（3）如果两个对象使用equals()方法判断为相等，则hashCode()方法也应该相等。
（4）如果两个对象使用equals()方法判断为不相等，则不要求hashCode()也必须不相等；但是开发人员应该认识到，不相等的对象产生不相同的hashCode可以提高哈希表的性能。
2、hashCode()的作用
总的来说，hashCode()在哈希表中起作用，如HashSet、HashMap等。
当我们向哈希表(如HashSet、HashMap等)中添加对象object时，首先调用hashCode()方法计算object的哈希码，通过哈希码可以直接定位object在哈希表中的位置(一般是哈希码对哈希表大小取余)。如果该位置没有对象，可以直接将object插入该位置；如果该位置有对象(可能有多个，通过链表实现)，则调用equals()方法比较这些对象与object是否相等，如果相等，则不需要保存object；如果不相等，则将该对象加入到链表中。
这也就解释了为什么equals()相等，则hashCode()必须相等。如果两个对象equals()相等，则它们在哈希表(如HashSet、HashMap等)中只应该出现一次；如果hashCode()不相等，那么它们会被散列到哈希表的不同位置，哈希表中出现了不止一次。
实际上，在JVM中，加载的对象在内存中包括三部分：对象头、实例数据、填充。其中，对象头包括指向对象所属类型的指针和MarkWord，而MarkWord中除了包含对象的GC分代年龄信息、加锁状态信息外，还包括了对象的hashcode；对象实例数据是对象真正存储的有效信息；填充部分仅起到占位符的作用, 原因是HotSpot要求对象起始地址必须是8字节的整数倍。
三、String中equals()和hashCode()的实现
String类中相关实现代码如下：
通过代码可以看出以下几点：
1、String的数据是final的，即一个String对象一旦创建，便不能修改；形如String s = "hello"; s = "world";的语句，当s = "world"执行时，并不是字符串对象的值变为了"world"，而是新建了一个String对象，s引用指向了新对象。
2、String类将hashCode()的结果缓存为hash值，提高性能。
3、String对象equals()相等的条件是二者同为String对象，长度相同，且字符串值完全相同；不要求二者是同一个对象。
4、String的hashCode()计算公式为：s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
关于hashCode()计算过程中，为什么使用了数字31，主要有以下原因：
1、使用质数计算哈希码，由于质数的特性，它与其他数字相乘之后，计算结果唯一的概率更大，哈希冲突的概率更小。
2、使用的质数越大，哈希冲突的概率越小，但是计算的速度也越慢；31是哈希冲突和性能的折中，实际上是实验观测的结果。
3、JVM会自动对31进行优化：31 * i == (i << 5) - i
四、如何重写hashCode()
本节先介绍重写hashCode()方法应该遵守的原则，再介绍通用的hashCode()重写方法。
1、重写hashcode()的原则
通过前面的描述我们知道，重写hashCode需要遵守以下原则：
（1）如果重写了equals()方法，检查条件“两个对象使用equals()方法判断为相等，则hashCode()方法也应该相等”是否成立，如果不成立，则重写hashCode ()方法。
（2）hashCode()方法不能太过简单，否则哈希冲突过多。
（3）hashCode()方法不能太过复杂，否则计算复杂度过高，影响性能。
2、hashCode()重写方法
《Effective Java》中提出了一种简单通用的hashCode算法。
A、初始化一个整形变量，为此变量赋予一个非零的常数值，比如int result = 17;
B、选取equals方法中用于比较的所有域（之所以只选择equals()中使用的域，是为了保证上述原则的第1条），然后针对每个域的属性进行计算：
(1) 如果是boolean值，则计算f ? 1:0
(2) 如果是bytecharshortint,则计算(int)f
(3) 如果是long值，则计算(int)(f ^ (f >>> 32))
(4) 如果是float值，则计算Float.floatToIntBits(f)
(5) 如果是double值，则计算Double.doubleToLongBits(f)，然后返回的结果是long,再用规则(3)去处理long,得到int
(6) 如果是对象应用，如果equals方法中采取递归调用的比较方式，那么hashCode中同样采取递归调用hashCode的方式。否则需要为这个域计算一个范式，比如当这个域的值为null的时候，那么hashCode 值为0
(7) 如果是数组，那么需要为每个元素当做单独的域来处理。java.util.Arrays.hashCode方法包含了8种基本类型数组和引用数组的hashCode计算，算法同上。
C、最后，把每个域的散列码合并到对象的哈希码中。
下面通过一个例子进行说明。在该例中，Person类重写了equals()方法和hashCode()方法。因为equals()方法中只使用了name域和age域，所以hashCode()方法中，也只计算name域和age域。
对于String类型的name域，直接使用了String的hashCode()方法；对于int类型的age域，直接用其值作为该域的hash。
一、Map概述
首先先看Map的结构示意图
图1
Map： “键值”对映射的抽象接口。该映射不包括重复的键，一个键对应一个值。
SortedMap： 有序的键值对接口，继承Map接口。
NavigableMap： 继承SortedMap，具有了针对给定搜索目标返回最接近匹配项的导航方法的接口。
AbstractMap： 实现了Map中的绝大部分函数接口。它减少了“Map的实现类”的重复编码。
Dictionary： 任何可将键映射到相应值的类的抽象父类。目前被Map接口取代。
TreeMap： 有序散列表，实现SortedMap 接口，底层通过红黑树实现。
HashMap： 是基于“拉链法”实现的散列表。底层采用“数组+链表”实现。
WeakHashMap： 基于“拉链法”实现的散列表。
HashTable： 基于“拉链法”实现的散列表。
总结如下：
图2
他们之间的区别：
图3
二、内部哈希： 哈希映射技术
几乎所有通用Map都使用哈希映射技术。对于我们程序员来说我们必须要对其有所了解。
哈希映射技术是一种就元素映射到数组的非常简单的技术。由于哈希映射采用的是数组结果，那么必然存在一中用于确定任意键访问数组的索引机制，该机制能够提供一个小于数组大小的整数，我们将该机制称之为哈希函数。在Java中我们不必为寻找这样的整数而大伤脑筋，因为每个对象都必定存在一个返回整数值的hashCode方法，而我们需要做的就是将其转换为整数，然后再将该值除以数组大小取余即可。如下
图4
下面是HashMap、HashTable的：
图5
位置的索引就代表了该节点在数组中的位置。下图是哈希映射的基本原理图
图6
在该图中1-4步骤是找到该元素在数组中位置，5-8步骤是将该元素插入数组中。在插入的过程中会遇到一点点小挫折。在众多肯能存在多个元素他们的hash值是一样的，这样就会得到相同的索引位置，也就说多个元素会映射到相同的位置，这个过程我们称之为“冲突”。解决冲突的办法就是在索引位置处插入一个链接列表，并简单地将元素添加到此链接列表。当然也不是简单的插入，在HashMap中的处理过程如下：获取索引位置的链表，如果该链表为null，则将该元素直接插入，否则通过比较是否存在与该key相同的key，若存在则覆盖原来key的value并返回旧值，否则将该元素保存在链头（最先保存的元素放在链尾）。下面是HashMap的put方法，该方法详细展示了计算索引位置，将元素插入到适当的位置的全部过程：
图7
HashMap的put方法展示了哈希映射的基本思想，其实如果我们查看其它的Map，发现其原理都差不多！
三、Map优化
首先我们这样假设，假设哈希映射的内部数组的大小只有1，所有的元素都将映射该位置（0），从而构成一条较长的链表。由于我们更新、访问都要对这条链表进行线性搜索，这样势必会降低效率。我们假设，如果存在一个非常大数组，每个位置链表处都只有一个元素，在进行访问时计算其 index 值就会获得该对象，这样做虽然会提高我们搜索的效率，但是它浪费了控件。诚然，虽然这两种方式都是极端的，但是它给我们提供了一种优化思路：使用一个较大的数组让元素能够均匀分布。 在Map有两个会影响到其效率，一是容器的初始化大小、二是负载因子。
3.1、调整实现大小
在哈希映射表中，内部数组中的每个位置称作“存储桶”(bucket)，而可用的存储桶数（即内部数组的大小）称作容量 (capacity)，我们为了使Map对象能够有效地处理任意数的元素，将Map设计成可以调整自身的大小。我们知道当Map中的元素达到一定量的时候就会调整容器自身的大小，但是这个调整大小的过程其开销是非常大的。调整大小需要将原来所有的元素插入到新数组中。我们知道index = hash(key) % length。这样可能会导致原先冲突的键不在冲突，不冲突的键现在冲突的，重新计算、调整、插入的过程开销是非常大的，效率也比较低下。所以，如果我们开始知道Map的预期大小值，将Map调整的足够大，则可以大大减少甚至不需要重新调整大小，这很有可能会提高速度。 下面是HashMap调整容器大小的过程，通过下面的代码我们可以看到其扩容过程的复杂性：
图8
3.2、负载因子
为了确认何时需要调整Map容器，Map使用了一个额外的参数并且粗略计算存储容器的密度。在Map调整大小之前，使用”负载因子”来指示Map将会承担的“负载量”，也就是它的负载程度，当容器中元素的数量达到了这个“负载量”，则Map将会进行扩容操作。负载因子、容量、Map大小之间的关系如下：负载因子 * 容量 > map大小 —–>调整Map大小。
例如：如果负载因子大小为0.75（HashMap的默认值），默认容量为11，则 11 * 0.75 = 8.25 = 8，所以当我们容器中插入第八个元素的时候，Map就会调整大小。
负载因子本身就是在控件和时间之间的折衷。当我使用较小的负载因子时，虽然降低了冲突的可能性，使得单个链表的长度减小了，加快了访问和更新的速度，但是它占用了更多的控件，使得数组中的大部分控件没有得到利用，元素分布比较稀疏，同时由于Map频繁的调整大小，可能会降低性能。但是如果负载因子过大，会使得元素分布比较紧凑，导致产生冲突的可能性加大，从而访问、更新速度较慢。所以我们一般推荐不更改负载因子的值，采用默认值0.75.
平时大家是否都会写类似这样的代码：
图1
条件少还好，一旦 else if 过多这里的逻辑将会比较混乱，并很容易出错。
比如这样：
图2
刚开始条件较少，也就没管那么多直接写的；现在功能多了导致每次新增一个 else 条件我都得仔细核对，生怕影响之前的逻辑。
重构之后这里的结构如下：
图3
最后直接变为两行代码，简洁了许多。
而之前所有的实现逻辑都单独抽取到其他实现类中。
图4
图5
这样每当我需要新增一个 else 逻辑，只需要新增一个类实现同一个接口便可完成。每个处理逻辑都互相独立互不干扰。
图6
按照目前的实现画了一个草图。
整体思路如下：
定义一个 InnerCommand 接口，其中有一个 process 函数交给具体的业务实现。
根据自己的业务，会有多个类实现 InnerCommand 接口；这些实现类都会注册到 Spring Bean 容器中供之后使用。
通过客户端输入命令，从 Spring Bean 容器中获取一个 InnerCommand 实例。
执行最终的 process 函数。
主要想实现的目的就是不在有多个判断条件，只需要根据当前客户端的状态动态的获取 InnerCommand 实例。
从源码上来看最主要的就是 InnerCommandContext 类，他会根据当前客户端命令动态获取 InnerCommand 实例。
图7
第一步是获取所有的 InnerCommand 实例列表。
根据客户端输入的命令从第一步的实例列表中获取类类型。
根据类类型从 Spring 容器中获取具体实例对象。
因此首先第一步需要维护各个命令所对应的类类型。
图8
所以在之前的枚举中就维护了命令和类类型的关系，只需要知道命令就能知道他的类类型。
这样才能满足只需要两行代码就能替换以前复杂的 if else，同时也能灵活扩展。
图9
当然还可以做的更灵活一些，比如都不需要显式的维护命令和类类型的对应关系。
只需要在应用启动时扫描所有实现了 InnerCommand 接口的类即可，在 cicada 中有类似实现，感兴趣的可以自行查看。
这样一些小技巧希望对你有所帮助。
1. 简介
从诞生开始，Java 就支持线程、锁等关键的并发概念。这篇文章旨在为使用了多线程的 Java 开发者理解 Core Java 中的并发概念以及使用方法。
2. 概念
2.1 竞争条件
多个线程对共享资源执行一系列操作，根据每个线程的操作顺序可能存在几种结果，这时出现竞争条件。下面的代码不是线程安全的，而且可以不止一次地初始化 value，因为 check-then-act（检查 null，然后初始化），所以延迟初始化的字段不具备原子性：
2.2 数据竞争
两个或多个线程试图访问同一个非 final 变量并且不加上同步机制，这时会发生数据竞争。没有同步机制可能导致这样的情况，线程执行过程中做出其他线程无法看到的更改，因而导致读到修改前的数据。这样反过来可能又会导致无限循环、破坏数据结构或得到错误的计算结果。下面这段代码可能会无限循环，因为读线程可能永远不知道写线程所做的更改：
3. Java 内存模型：happens-before 关系
Java 内存模型定义基于一些操作，比如读写字段、 Monitor 同步等。这些操作可以按照 happens-before 关系进行排序。这种关系可用来推断一个线程何时看到另一个线程的操作结果，以及构成一个程序同步后的所有信息。
happens-before 关系具备以下特性：
在线程开始所有操作前调用 Thread#start
在获取 Monitor 前，释放该 Monitor
在读取 volatile 变量前，对该变量执行一次写操作
在写入 final 变量前，确保在对象引用已存在
线程中的所有操作应在 Thread#join 返回之前完成
4. 标准同步特性
4.1 synchronized 关键字
使用 synchronized 关键字可以防止不同线程同时执行相同代码块。由于进入同步执行的代码块之前加锁，受该锁保护的数据可以在排他模式下操作，从而让操作具备原子性。此外，其他线程在获得相同的锁后也能看到操作结果。
也可以在方法上加 synchronized 关键字
表2 当整个方法都标记 synchronized 时使用的 Monitor
锁是可重入的。如果线程已经持有锁，它可以再次成功地获得该锁。
竞争的程度对获取 Monitor 的方式有影响
表3： Monitor 状态
4.2 wait/notify
wait/notify/notifyAll 方法在 Object 类中声明。如果之前设置了超时，线程进入 WAITING 或 TIMED_WAITING 状态前保持 wait状态。要唤醒一个线程，可以执行下列任何操作：
另一个线程调用 notify 将唤醒任意一个在 Monitor 上等待的线程。
另一个线程调用 notifyAll 将唤醒所有在等待 Monitor 上等待的线程。
调用 Thread#interrupt 后会抛出 InterruptedException 异常。
最常见的模式是条件循环：
请记住，在对象上调用 wait/notify/notifyAll，需要首先获得该对象的锁
在检查等待条件的循环中保持等待：这解决了另一个线程在等待开始之前即满足条件时的计时问题。 此外，这样做还可以让你的代码免受可能（也的确会）发生的虚假唤醒
在调用 notify/notifyAll 前，要确保满足等待条件。如果不这样做会引发通知，然而没有线程能够避免等待循环
4.3 volatile 关键字
volatile 解决了可见性问题，让修改成为原子操作。由于存在 happens-before 关系，在接下来读取 volatile 变量前，先对 volatile 变量进行写操作。 从而保证了对该字段的任何读操作都能督读到最近一次修改后的值。
4.4 Atomic
java.util.concurrent.atomic package 包含了一组类，它们用类似 volatile 的无锁方式支持单个值的原子复合操作。
使用 AtomicXXX 类，可以实现 check-then-act 原子操作：
AtomicInteger 和 AtomicLong 都提供原子 increment/decrement 操作：
如果你希望有这样一个计数器，不需要在获取计数的时候具备原子性，可以考虑用 LongAdder 取代 AtomicLong/AtomicInteger。 LongAdder 能在多个单元中存值并在需要时增加计数，因此在竞争激烈的情况下表现更好。
4.5 ThreadLocal
一种在线程中包含数据但不用锁的方法是使用 ThreadLocal 存储。从概念上讲，ThreadLocal 可以看做每个 Thread 存有一份自己的变量。Threadlocal 通常用于保存每个线程的值，比如“当前事务”或其他资源。 此外，还可以用于维护每个线程的计数器、统计信息或 ID 生成器。
一、synchronized关键字
1.1、简介
synchronized，我们谓之锁，主要用来给方法、代码块加锁。当某个方法或者代码块使用synchronized时，那么在同一时刻至多仅有有一个线程在执行该段代码。当有多个线程访问同一对象的加锁方法/代码块时，同一时间只有一个线程在执行，其余线程必须要等待当前线程执行完之后才能执行该代码段。但是，其余线程是可以访问该对象中的非加锁代码块的。
synchronized主要包括两种方法：synchronized 方法、synchronized 块。
1.2、synchronized 方法
通过在方法声明中加入 synchronized关键字来声明 synchronized 方法。如：
ynchronized方法控制对类成员变量的访问。它是如何来避免类成员变量的访问控制呢？我们知道方法使用了synchronized关键字表明该方法已加锁，在任一线程在访问改方法时都必须要判断该方法是否有其他线程在“独占”。每个类实例对应一个把锁，每个synchronized方法都必须调用该方法的类实例的锁方能执行，否则所属线程阻塞，方法一旦执行，就独占该锁，直到从该方法返回时才将锁释放，被阻塞的线程方能获得该锁。
其实synchronized方法是存在缺陷的，如果我们将一个很大的方法声明为synchronized将会大大影响效率的。如果多个线程在访问一个synchronized方法，那么同一时刻只有一个线程在执行该方法，而其他线程都必须等待，但是如果该方法没有使用synchronized，则所有线程可以在同一时刻执行它，减少了执行的总时间。所以如果我们知道一个方法不会被多个线程执行到或者说不存在资源共享的问题，则不需要使用synchronized关键字。但是如果一定要使用synchronized关键字，那么我们可以synchronized代码块来替换synchronized方法。
1.3、synchronized 块
synchronized代码块所起到的作用和synchronized方法一样，只不过它使临界区变的尽可能短了，换句话说：它只把需要的共享数据保护起来，其余的长代码块留出此操作。语法如下：
如果我们需要以这种方式来使用synchronized关键字,那么必须要通过一个对象引用来作为参数,通常这个参数我们常使用为this.
对于synchronized(this)有如下理解：
1、当两个并发线程访问同一个对象object中的这个synchronized(this)同步代码块时，一个时间内只能有一个线程得到执行。另一个线程必须等待当前线程执行完这个代码块以后才能执行该代码块。
2、然而，当一个线程访问object的一个synchronized(this)同步代码块时，另一个线程仍然可以访问object中的非synchronized(this)同步代码块。
3、尤其关键的是，当一个线程访问object的一个synchronized(this)同步代码块时，其他线程对object中所有其他synchronized(this)同步代码块得访问将被阻塞。
4、第三个例子同样适用其他同步代码块。也就是说，当一个线程访问object的一个synchronized(this)同步代码块时，它就获得了这个object的对象锁。结果，其他线程对该object对象所有同步代码部分的访问都将被暂时阻塞。
5、以上规则对其他对象锁同样适用
.4、进阶
在java多线程中存在一个“先来后到”的原则，也就是说谁先抢到钥匙，谁先用。我们知道为避免资源竞争产生问题，java使用同步机制来避免，而同步机制是使用锁概念来控制的。那么在Java程序当中，锁是如何体现的呢？这里我们需要弄清楚两个概念：
什么是锁？
什么是锁？在日常生活中，它就是一个加在门、箱子、抽屉等物体上的封缄器，防止别人偷窥或者偷盗，起到一个保护的作用。在java中同样如此，锁对对象起到一个保护的作用，一个线程如果独占了某个资源，那么其他的线程别想用，想用？等我用完再说吧！
在java程序运行环境中，JVM需要对两类线程共享的数据进行协调：
1、保存在堆中的实例变量
2、保存在方法区中的类变量。
在java虚拟机中，每个对象和类在逻辑上都是和一个监视器相关联的。对于对象来说，相关联的监视器保护对象的实例变量。 对于类来说，监视器保护类的类变量。如果一个对象没有实例变量，或者说一个类没有变量，相关联的监视器就什么也不监视。
为了实现监视器的排他性监视能力，java虚拟机为每一个对象和类都关联一个锁。代表任何时候只允许一个线程拥有的特权。线程访问实例变量或者类变量不需锁。 如果某个线程获取了锁，那么在它释放该锁之前其他线程是不可能获取同样锁的。一个线程可以多次对同一个对象上锁。对于每一个对象，java虚拟机维护一个加锁计数器，线程每获得一次该对象，计数器就加1，每释放一次，计数器就减 1，当计数器值为0时，锁就被完全释放了。
java编程人员不需要自己动手加锁，对象锁是java虚拟机内部使用的。在java程序中，只需要使用synchronized块或者synchronized方法就可以标志一个监视区域。当每次进入一个监视区域时，java 虚拟机都会自动锁上对象或者类。（摘自java的锁机制）。
锁的是什么？
在这个问题之前我们必须要明确一点：无论synchronized关键字加在方法上还是对象上，它取得的锁都是对象。在java中每一个对象都可以作为锁，它主要体现在下面三个方面：
对于同步方法，锁是当前实例对象。
对于同步方法块，锁是Synchonized括号里配置的对象。
对于静态同步方法，锁是当前对象的Class对象。
首先我们先看下面例子：
部分运行结果：
这个结果与我们预期的结果有点不同（这些线程在这里乱跑），照理来说，run方法加上synchronized关键字后，会产生同步效果，这些线程应该是一个接着一个执行run方法的。在上面LZ提到，一个成员方法加上synchronized关键字后，实际上就是给这个成员方法加上锁，具体点就是以这个成员方法所在的对象本身作为对象锁。但是在这个实例当中我们一共new了10个ThreadTest对象，那个每个线程都会持有自己线程对象的对象锁，这必定不能产生同步的效果。所以：如果要对这些线程进行同步，那么这些线程所持有的对象锁应当是共享且唯一的！
这个时候synchronized锁住的是那个对象？它锁住的就是调用这个同步方法对象。就是说threadTest这个对象在不同线程中执行同步方法，就会形成互斥。达到同步的效果。所以将上面的new Thread(new ThreadTest_01(),”Thread_” + i).start(); 修改为new Thread(threadTest,”Thread_” + i).start();就可以了。
对于同步方法，锁是当前实例对象。
上面实例是使用synchronized方法，我们在看看synchronized代码块：
运行结果：
在main方法中我们创建了一个String对象lock，并将这个对象赋予每一个ThreadTest2线程对象的私有变量lock。我们知道java中存在一个字符串池，那么这些线程的lock私有变量实际上指向的是堆内存中的同一个区域，即存放main函数中的lock变量的区域，所以对象锁是唯一且共享的。线程同步！！
在这里synchronized锁住的就是lock这个String对象。
对于同步方法块，锁是Synchonized括号里配置的对象。
运行结果：
在这个实例中，run方法使用的是一个同步方法，而且是static的同步方法，那么这里synchronized锁的又是什么呢？我们知道static超脱于对象之外，它属于类级别的。所以，对象锁就是该静态放发所在的类的Class实例。由于在JVM中，所有被加载的类都有唯一的类对象，在该实例当中就是唯一的 ThreadTest_03.class对象。不管我们创建了该类的多少实例，但是它的类实例仍然是一个！所以对象锁是唯一且共享的。线程同步！！
对于静态同步方法，锁是当前对象的Class对象。
如果一个类中定义了一个synchronized的static函数A，也定义了一个synchronized的instance函数B，那么这个类的同一对象Obj,在多线程中分别访问A和B两个方法时，不会构成同步，因为它们的锁都不一样。A方法的锁是Obj这个对象，而B的锁是Obj所属的那个Class。
锁的升级
java中锁一共有四种状态，无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态，它会随着竞争情况逐渐升级。锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率。下面主要部分主要是对博客：聊聊并发（二）Java SE1.6中的Synchronized的总结。
锁自旋
我们知道在当某个线程在进入同步方法/代码块时若发现该同步方法/代码块被其他现在所占，则它就要等待，进入阻塞状态，这个过程性能是低下的。
在遇到锁的争用或许等待事，线程可以不那么着急进入阻塞状态，而是等一等，看看锁是不是马上就释放了，这就是锁自旋。锁自旋在一定程度上可以对线程进行优化处理。
偏向锁
偏向锁主要为了解决在没有竞争情况下锁的性能问题。在大多数情况下锁锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。当某个线程获得锁的情况，该线程是可以多次锁住该对象，但是每次执行这样的操作都会因为CAS（CPU的Compare-And-Swap指令）操作而造成一些开销消耗性能，为了减少这种开销，这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。
当有其他线程在尝试着竞争偏向锁时，持有偏向锁的线程就会释放锁。
锁膨胀
多个或多次调用粒度太小的锁，进行加锁解锁的消耗，反而还不如一次大粒度的锁调用来得高效。
轻量级锁
轻量级锁能提升程序同步性能的依据是“对于绝大部分的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。轻量级锁在当前线程的栈帧中建立一个名为锁记录的空间，用于存储锁对象目前的指向和状态。如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了CAS操作，因此在有竞争的情况下，轻量级锁会比传统的重量级锁更慢。
