1.JIT即时编译器
类的加载
java文件编译成class文件，然后类加载，类的连接（校验，准备（会初始化static成员，会赋值final static成员），解释（符号引用转为直接引用）），类的初始化成为字节码，jit/解释器将字节码翻译成机器码。
类加载：bootstraploader加载jdk工具类，extclassloader加载java扩展库类，appclassloader加载应用的类。
jit优化：
1）逃逸分析，对于只存在一个方法中的对象在栈上分配，
对于在局部方法中new 的类因为只在一个线程中执行，不存在锁竞争，就不需要synchronized等，锁消除。
标量替换
2）方法的合并，方法内联
调用的小方法可以合并到本地代码，减少方法的调用。
2.分布式锁
分布式锁实现方案：数据库库表控制，zookeeper，redis。
数据库的就是通过相应的表控制。
zookeeper分布式锁的实现原理：建立持久的父节点，然后每次申请锁时在这个父节点下建立瞬时有序的节点，节点id最小的获取锁。watcher来监听锁变更事件和节点删除事件，和自己能否获取到锁。新建和删除节点比较耗时间，还有大量的wacher事件，性能不是很好。如果对性能要求不是很高的应用，建议采用。
redis分布式锁原理：setnx并有过期时间，redis的单线程原子性，注意获取锁后要删除锁（也可以依赖过期时间）。性能好，不过如果是集群下，master挂了，还没能及时同步到slave，这个时候就可能出现多个client获取到锁。
redlock：基于redis和netty，多个节点请求获取锁，超过半数才算成功获取锁，避免了redis的master崩溃切换master多个client获取锁的问题。
3.分布式事务
分布式事务解决方案：
1）2pc，2阶段提交，准备阶段，执行；提交阶段：各个资源管理器执行就绪，就提交，如果有未执行成功就回滚。如果有个执行时间很长，阻塞问题，就会等待很长时间。如果期间网络有问题，尤其是回滚可能有问题，也会导致数据不一致。
2）3pc，3阶段提交，将准备阶段分为询问是否可以执行和执行两个阶段，如果都说能执行才执行，都执行额成功了才提交。同时每个阶段都设置了超时，就避免了阻塞的问题。但是仍然解决不了网络问题，数据不一致的问题。
3）tcc, try-commit-cancel, 执行-提交-回滚，柔性事物，基于2pc的，最终一致性，没有资源上都要tcc，然后事物管理器统一tcc。其基本实现有使用mq来达到最终一致性。
4）seata，阿里分布式事务中间件，在xa中加入了协调器。
