java

未提交读

读写提交

可重复读

串行化

脏读，幻读

REQUIRED(0),

SUPPORTS(1),

MANDATORY(2),

REQUIRES_NEW(3),

NOT_SUPPORTED(4),

NEVER(5),

NESTED(6);

原子性

一致性

隔离性

持久化

说明

如果子事务回滚，会发生什么？

如果父事务回滚，会发生什么？

事务的提交，是什么情况？

主要包括，web json tomcat webmvc等基础组件，提供web开发场景的底层依赖

如果请求的是页面和数据就用@controller，如果只是请求数据就用@RestController

单数据源配置spring-datasource-url配置项，多数据源用spring-datasource.*.jdbc-url

第一步：在配置文件中配置多个数据源配置链接信息 例如 spring.datasource.kobe.jdbc-url,spring.dataso              urce.track.jdbc-url 
第二步：@Configuration 注解到datasouconfig类上 配置多个数据源和jdbc链接实例 详见1-1图
第三步：使用@resource和@authwired注解 来使用jdbc链接实

spring boot集成mybaits 需要集成这个包mybatis-spring-boot-starter

mybatis由mapper配置文件，mapper接口，执行器，会话等组成
1.mapper配置文件 基于xml的配置文件来实现
2.mapper接口 是指自定义的操作接口 也就是dao接口，与xml文件对应
3.executor执行器 执行sql 是mybatis的核心接口之一
4.sqlsession mybatis的关键对象，类似于jdbc的链接（connection），sqlsession完全包含数据库所有的执行sql操作方法，底层封装                     了jdbc
5.sqlsessionFactory(会话工厂)mybatis的关键对象 sqlsessionFactory可通过sqlsessionFactoryBuilder获取
6.sqlsessionFactoryBuilder构造器 用于解析配置文件 属性配置，别名配置 拦截器配置 数据源事务

1.加载mapper映射的sql配置文件,或者注解sql的相关内容
2.创建会话工厂，通过读取数据源配置来创建会话工厂sqlsessionFactory
3.创建会话 通过会话工厂来创建会话对象 会话对象是一个接口包含 增删改查
4.创建执行器 会话不能操作数据库 只能通过执行器来操作数据库
5.封装sqld对象 将待执行的slq封装成一个对象 该对象包括sql语句 输入参数和返回结果信息
6.操作数据库 使用执行器执行sql 将sql结果返回

特别重点：sqlsessionFactory创建会话工厂 mapper提供sql映射

一种对象/关联映射工具来管理Java应用中的关系数据，通过xml或者注解来描述对象-关系表之间的映射关系，并将实体持久化到数据库中

配置文件详解

描述

具体方法描述

@Scheduled是单线程模式的 如果有多个的话 会产生线程阻塞需要加一个线程池
1.增加多线程配置类 配置定时任务

基本概念

1.注意集群环境下时钟必须同步

2.初始化quzrtz数据库，可以在官网中查找
3修改配置文件
4.定义定时任务增加了两个注解，@PersistJobDataAfterExecution（持久化任务信息）和@DisallowConcurrenExecution（禁止并发执行）

支持类型

连接客户端程序

redis数据缓存

redis实现session共享

子主题

Actuauor是spring boot应用系统监控的框架也就是应用程序内部监控，它的核心是端点 内置了很多组件例如 health env beans等
还可以与外部系统应用进行整合

Actuator内置端点

自定义端点

(方法区的一部分)用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到常量池中
1.8以前放在方法区，大小受限于方法区。1.8以后放在堆中，主要由字面量（字符串，基本数据类型的值，常量值）和符合引用组成。。

将外部的class文件加载到虚拟机，存储到方法区内  即二进制字节流

 1）通过一个类的全限定名来获取定义此类的二进制字节流。
 2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
 3）在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据 的访问入口。

数组类通过java虚拟机直接创建，不通过类加载器创建

确保加载进来的class文件包含的信息符合Java虚拟机的要求

文件格式的验证

元数据验证

字节码验证

符号引用验证

为类变量设置内存，设置初始化值

1.正式为类变量分配内存（仅是被static修饰的变量，不包括实例变量）
2.正式为类变量设置初始值 这些变量所使用的的内存都在方法区中进行分配

实例变量内存不在此处分配
则变量为常量（被final修饰）则赋值开发者定义的值

将常量池中的符号引用转换为直接引用。

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点 限定符7类符号引用进行，分别对应于常量池的CONSTANT_Class_info、 CONSTANT_Fieldref_info、CONSTANT_Methodref_info、 CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、 CONSTANT_MethodHandle_info和CONSTANT_InvokeDynamic_info 7种常量类型。

初始化类变量，静态语句块

初始化是指为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，
主要对类变量进行初始化。在Java中对类变量进行初始值设定有两种方式：
（1）声明类变量时指定初始值；
（2）使用静态代码块为类变量指定初始值。
JVM初始化步骤：
（1）假如这个类还没有被加载和连接，则程序先加载并连接该类；
（2）假如该类的直接父类还没有被初始化，则先初始化其直接父类；
（3）假如类中有初始化语句，则系统依次执行这些初始化语句。
类初始化时机：只有当对类主动使用的时候才会导致类的初始化，
类的主动使用包括以下6种：
创建类的实例，也就是new的方式；
访问某个类或接口的静态变量，或者对该静态变量赋值；
调用类的静态方法；
反射（如Class.forName("…")）；
初始化某个类的子类，则其父类也会被初始化；
Java虚拟机启动时被标明为启动类的类，直接使用java.exe命令来运行某个主类。

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当 有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承（Inheritance）的关系 来实现，而是都使用组合（Composition）关系来复用父加载器的代码。

如果一个类加载器收到了类加载的请求，它首先不会自己 去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是 如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈 自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自 己去加载。

使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着 它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在 rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加 载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有 使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为 java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object 类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。如果读者 有兴趣的话，可以尝试去编写一个与rt.jar类库中已有类重名的Java类，将会发现可以正常编 译，但永远无法被加载运行[2]。

双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现却非常简单，实现双亲
委派的代码都集中在java.lang.ClassLoader的loadClass（）方法之中，如代码清单7-10所示， 逻辑清晰易懂：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass（）方 法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出 ClassNotFoundException异常后，再调用自己的findClass（）方法进行加载。
方法说明

getParent() 返回该类加载器的父类加载器。
loadClass(String name) 加载名称为 二进制名称为name 的类，返回的结果是 java.lang.Class 类的实例。
findClass(String name) 查找名称为 name 的类，返回的结果是 java.lang.Class 类的实例。
findLoadedClass(String name) 查找名称为 name 的已经被加载过的类，返回的结果是 java.lang.Class 类的实例。
resolveClass(Class<?> c) 链接指定的 Java 类。

这个算法的基本思 路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所 走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连 （用图论的话来说，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。如 图3-1所示，对象object 5、object 6、object 7虽然互相有关联，但是它们到GC Roots是不可达 的，所以它们将会被判定为是可回收的对象。

虚拟机栈中引用的对象

方法区中类静态属性引用的对象

方法区中常量引用的对象

本地方法栈中JNI（即一般说的Native方法）引用的对象。

java 并不通过引用计数器来判定对象的存活 而是通过可达性分析算法判定对象的存活。即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历再次标记过程。
标记的前提是对象在进行可达性分析后发现没有与GC Roots相连接的引用链。
1).第一次标记并进行一次筛选。
    筛选的条件是此对象是否有必要执行finalize()方法。
    当对象没有覆盖finalize方法，或者finzlize方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”，对象被回收。
2).第二次标记
    如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会被放置在一个名为：F-Queue的队列之中，并在稍后由一条虚拟机自动建立的、低优先级的Finalizer线程去执行。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。这样做的原因是，如果一个对象finalize（）方法中执行缓慢，或者发生死循环（更极端的情况），将很可能会导致F-Queue队列中的其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃。
    Finalize（）方法是对象脱逃死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，如果对象要在finalize（）中成功拯救自己----只要重新与引用链上的任何的一个对象建立关联即可，譬如把自己赋值给某个类变量或对象的成员变量，那在第二次标记时它将移除出“即将回收”的集合。如果对象这时候还没逃脱，那基本上它就真的被回收了。

无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象的引 用链是否可达，判定对象是否存活都与“引用”有关。在JDK 1.2以前，Java中的引用的定义很 传统：如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块 内存代表着一个引用。这种定义很纯粹，但是太过狭隘，一个对象在这种定义下只有被引用 或者没有被引用两种状态，对于如何描述一些“食之无味，弃之可惜”的对象就显得无能为 力。我们希望能描述这样一类对象：当内存空间还足够时，则能保留在内存之中；如果内存 空间在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这 样的应用场景。

强引用

软引用

弱引用

虚引用

分为标记和清除两个阶段

步骤：首先标记出所有需要回收的对象，在标记完成后统一回收所有 被标记的对象
         标记清除法是最基础的算法 所有的算法都是在此基础上是因为后续的收集算法都是基于这种思路并对其不足进行改进而得到 的

存在的问题：1.标记和清除效率不高
                  2.空间问题 标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程 序运行过程中需要分配较大对                      象时，无法找到足够的连续内存而不得不提前触发另一次垃圾 收集动作。

上图中等方块的假设是2M，小一些的是1M，大一些的是4M。等我们回收完，内存就会切成了很多段。我们知道开辟内存空间时，需要的是连续的内存区域，这时候我们需要一个2M的内存区域，其中有2个1M是没法用的。这样就导致，其实我们本身还有这么多的内存的，但却用不了。

复制算法将内存划分为两个区间，在任意时间点，所有动态分配的对象都只能分配在其中一个区间（称为活动区间），而另外一个区间（称为空闲区间）则是空闲的。
当有效内存空间耗尽时，JVM将暂停程序运行，开启复制算法GC线程。接下来GC线程会将活动区间内的存活对象，全部复制到空闲区间，且严格按照内存地址依次排列，与此同时，GC线程将更新存活对象的内存引用地址指向新的内存地址。
         此时，空闲区间已经与活动区间交换，而垃圾对象现在已经全部留在了原来的活动区间，也就是现在的空闲区间。事实上，在活动区间转换为空间区间的同时，垃圾对象已经被一次性全部回收。

优点：实现简单  效率高
缺点： （1）缩小了原来内存的一般
          （2）如果对象的存活率很高，我们可以极端一点，假设是100%存活，那么我们需要将所有对象都复制一遍，并将所有引用地址                    重置一遍。复制这一工作所花费的时间，在对象存活率达到一定程度时，将会变的不可忽视。

复制算法要想使用，最起码对象的存活率要非常低才行，而且最重要的是，我们必须要克服50%内存的浪费。
，所以在老年代一般不能直接选用这种算法。

标记/整理算法与标记/清除算法非常相似，它也是分为两个阶段：标记和整理。
标记：它的第一个阶段与标记/清除算法是一模一样的，均是遍历GC Roots，然后将存活的对象标记。
整理：移动所有存活的对象，且按照内存地址次序依次排列，然后将末端内存地址以后的内存全部回收。因此，第二阶段才称为整理阶段。
标记/整理算法不仅可以弥补标记/清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价。
不过任何算法都会有其缺点，标记/整理算法唯一的缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。从效率上来说，标记/整理算法要低于复制算法。

当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，这种算 法并没有什么新的思想，只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆 分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代 中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付 出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间 对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。


效率：复制算法>标记/整理算法>标记/清除算法（此处的效率只是简单的对比时间复杂度，实际情况不一定如此）。

       内存整齐度：复制算法=标记/整理算法>标记/清除算法。

       内存利用率：标记/整理算法=标记/清除算法>复制算法。

图中展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。

特性：
这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。Stop The World

应用场景：
Serial收集器是虚拟机运行在Client模式下的默认新生代收集器。
串行的垃圾收集器有两种，Serial与Serial Old，一般两者搭配使用。新生代采用Serial，是利用复制算法；老年代使用Serial Old采用标记-整理算法。Client应用或者命令行程序可以，通过-XX:+UseSerialGC可以开启上述回收模式。

优势：
简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

特性：Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整 理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。

应用场景：如果在Server模式 下，那么它主要还有两大用途：一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge 收集器搭配使用[1]，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用

ParNew收集器

特性：
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。
Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点 是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到 一个可控制的吞吐量（Throughput）。

适用场景：停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高 吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不 需要太多交互的任务。

Parallel Scavenge收集器提供了两个参数来用于精确控制吞吐量，一是控制最大垃圾收集停顿时间的 -XX：MaxGCPauseMillis参数，二是控制吞吐量大小的 -XX：GCTimeRatio参数；

  “ -XX：MaxGCPauseMillis” 参数允许的值是一个大于0的毫秒数，收集器将尽可能的保证内存垃圾回收花费的时间不超过设定的值（但是，并不是越小越好，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的，如果设置的值太小，将会导致频繁GC，这样虽然GC停顿时间下来了，但是吞吐量也下来了）。

  “ -XX：GCTimeRatio”参数的值是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，默认值是99，就是允许最大1%（即1/（1+99））的垃圾收集时间。

  “-XX：UseAdaptiveSizePolicy”参数是一个开发，如果这个参数打开之后，虚拟机会根据当前系统运行情况收集监控信息，动态调整新生代的比例、老年大大小等细节参数，以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略。

特性：Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。
应用场景：在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

这个收集器是在JDK 1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old收集器外别无选择（Parallel Scavenge收集器无法与CMS收集器配合工作）。由于老年代Serial Old收集器在服务端应用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合

特性：CMS收集器是基于“标记—清除”算法实现，目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重 视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常 符合这类应用的需求。

优点：：并发收集、低停 顿
分为4步骤：初始标记（CMS initial mark）         初始标记仅仅只是 标记一下GC Roots能直接关联到的对象，速度很快
                 并发标记（CMS concurrent mark） 并发标记阶段就是进行GC RootsTracing 的过程
                 重新标记（CMS remark）         修正并发标记期间因用户程序继续运作而导致标记产生变 动的那一部分对象的标记记                                                                   录，   这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远 比并发标记的时间短。
                 并发清除（CMS concurrent sweep）并发清除阶段会清除你标记的对象。

缺点：1）CMS收集器无法处理浮动垃圾（什么是浮动垃圾：由于CMS并发清理阶段用户线程还在运行着，伴 随程序运行自然就还会有                                                           新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法 在当次收集中处理掉它                                                             们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃 圾）
         2）CMS是一款基于“标记—清除”算法实现的收集 会产生空间碎片过多 将会给分配大对象带来很多麻烦 往往会出现老年代还                                                           有 很大空间剩余，但是无法找到足够大的连续空间来分配当前对象
         3）CMS对cpu资源非常敏感（面向并发设计的程序都对CPU资源比较敏感在并发阶段，它虽然不会导致用户线程停顿，但是会因                                                   为占用了一部分线程（或者说CPU资 源）而导致应用程序变慢，总吞吐量会降低。CMS默认启动                                                     的回收线程数是（CPU数量 +3）/4，也）

概述：
优点：1）并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者 CPU核心）来缩短Stop-The-World                                 停顿的 时间，部分其他收集器原本需要停顿Java线程执行的 GC动作，G1收集器仍然可以通过并发的方式让Jav                                 a程序继续行。
         2）分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其 他收集器配合就能独立管理整个GC堆                                 但它能够采用不同的方式去处理新创建的对象和已 经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效                               果。     
         3）空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实 现的收集器，从局部（两个Region                                之间）上来看是基于“复制”算法实现的，但无论如何，这 两种算法都意味着G1运作期间不会产生内存空间碎片，                                收集后能提供规整的可用内存。这种 特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而                              提前触发下一 次GC。
          4）可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关 注点，但G1除了追求低停顿外，还能                                      建立可预测的停顿时间模型，能让使用者明确指定在一 个长度为M毫秒的时间片段内，消耗在垃圾收集上的                                      时间不得超过N毫秒，这几乎已经是实 时Java（RTSJ）的垃圾收集器的特征了。

如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为以下几个步骤：
                   初始标记（Initial Marking） 
                   并发标记（Concurrent Marking） 
                   最终标记（Final Marking） 
                   筛选回收（Live Data Counting and Evacuation）

开发人员仅仅需要声明以下参数即可：

-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=200

其中-XX:+UseG1GC为开启G1垃圾收集器，-Xmx32g 设计堆内存的最大内存为32G，-XX:MaxGCPauseMillis=200设置GC的最大暂停时间为200ms。如果我们需要调优，在内存大小一定的情况下，我们只需要修改最大暂停时间即可。

其次，G1将新生代，老年代的物理空间划分取消了。取而代之的是，G1算法将堆划分为若干个区域（Region），它仍然属于分代收集器。不过，这些区域的一部分包含新生代，新生代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间。老年代也分成很多区域，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样也就不会有cms内存碎片问题的存在了。

在G1中，还有一种特殊的区域，叫Humongous区域。 如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。这些巨型对象，默认直接会被分配在年老代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。

PS：在java 8中，持久代也移动到了普通的堆内存空间中，改为元空间。

线程隔离

跨函数传数据

ThreadLocal内部是一个map,每一个线程实例作为key value为你当前线程绑定的值

新的Key为ThreadLocal实例。

（1）拥有者发生了变化：新版本的ThreadLocalMap拥有者为Thread，早期版本的ThreadLocalMap拥有者为ThreadLocal。
（2）Key发生了变化：新版本的Key为ThreadLocal实例，早期版本的Key为Thread实例。与早期版本的ThreadLocalMap实现相比，新版本的主要优势为：
（1）每个ThreadLocalMap存储的“Key-Value对”数量变少。早期版本的“Key-Value对”数量与线程个数强关联，若线程数量多，则ThreadLocalMap存储的“Key-Value对”数量也多。新版本的ThreadLocalMap的Key为ThreadLocal实例，多线程情况下ThreadLocal实例比线程数少。
（2）早期版本ThreadLocalMap的拥有者为ThreadLocal，在Thread（线程）实例销毁后，ThreadLocalMap还是存在的；新版本的ThreadLocalMap的拥有者为Thread，现在当Thread实例销毁后，ThreadLocalMap也会随之销毁，在一定程度上能减少内存的消耗。

1.尽量使用private static final修饰ThreadLocal实例。使用private与final修饰符主要是为了尽可能不让他人修改、变更ThreadLocal变量的引用，使用static修饰符主要是为了确保ThreadLocal实例的全局唯一。

2.使用完之后要remove()  避免内存泄漏

Java对象包括三部分 对象头，对象体，对齐字节

无锁

偏向锁

轻量级锁

重量级锁

wait()方法的核心原理对象的wait()方法的核心原理大致如下：
（1）当线程调用了locko（某个同步锁对象）的wait()方法后，JVM会将当前线程加入locko监视器的WaitSet（等待集），等待被其他线程唤醒。
（2）当前线程会释放locko对象监视器的Owner权利，让其他线程可以抢夺locko对象的监视器。
（3）让当前线程等待，其状态变成WAITING。在线程调用了同步对象locko的wait()方法之后，同步对象locko的监视器内部状态大致如图2-15所示。

为什么Wait()后的线程状态为WAITING呢？此时WaitThread处于locko的监视器的WaitSet（等待集）中，等待被唤醒。

（1）当线程调用了locko（某个同步锁对象）的notify()方法后，JVM会唤醒locko监视器WaitSet中的第一条等待线程。
（2）当线程调用了locko的notifyAll()方法后，JVM会唤醒locko监视器WaitSet中的所有等待线程。
（3）等待线程被唤醒后，会从监视器的WaitSet移动到EntryList，线程具备了排队抢夺监视器Owner权利的资格，其状态从WAITING变成BLOCKED。
（4）EntryList中的线程抢夺到监视器的Owner权利之后，线程的状态从BLOCKED变成Runnable，具备重新执行的资格。在线程调用了同步对象locko的wait()或者notifyAll()方法之后，同步对象locko的监视器内部状态大致

wait()和notify方法一定要放到synchronized代码块中
为什么一定要放到synchronized代码块中呢？ 是因为对象锁监视器  JVM会将当前线程移入监视器的WaitSet队列所以必须通过synchronized()方法成为对象锁的监视器的Owner notify唤醒线程的时候需要将waitset里面的线程加入到entryset中 所以也是需要对象锁监视器

概念

解决内存的可见性问题方式

volatile关键字

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

悲观锁总是假设会发生最坏的情况，每次线程读取数据时，也会上锁。这样其他线程在读取数据时就会被阻塞，直到它拿到锁。传统的关系型数据库用到了很多悲观锁，比如行锁、表锁、读锁、写锁等。
存在的问题：1.多线程竞争加锁 线程上下文切换 影响性能|
                  2.当前线程获取到锁 其他线程则只能挂起等待
                  3.如果一个优先级高的线程等待一个优先级低的线程释放锁，就会导致线程的优先级倒置，从而引发性能风险。

死锁是指两个或者两个以上的线程因抢占锁造成的相互等待现象 ，常见的 AB-BA模式
解决：Java8中提供了ThreadMAXBean接口来监控线程的，包括一下两个死锁的线程方法
         1.findDeadlocakedThreads用于检测由于抢占JUC显示锁，Java内置锁引起的死锁线程
         2.findMonitorDeadlockedThreads 仅仅用于检测内置锁引起的死锁线程
         3.监视到死锁后可中断线程

数据库定义语言，常用关键字有create，drop, alter

数据操作语句，常用关键字 insert update delete select 只对表内数据操作

数据控制语句，定义了库，表，字段用户的访问权限和安全级别 关键字grant,revoke等

存储数据库对象信息，用户表信息，列信息，权限信息，字符信息，分区信息

存储了系统集群信息

存储系统用户权限信息

系统自建测试库 任何人都可以使用

1.having和where的区别：having是对聚合后的结果进行条件的过滤，而where是在聚合前就过滤，尽可能先试用where先过滤 这样 结   果集减少 聚合效率提高

将要两个表的数据按照条件查询 并且将两个sql的结果直接合并在一起 这个时候就要用到 union,union all
区别：union all 是把结果集直接合并在一起 而 union 是将union all结果集去重了一遍。

INT类型

1.使用order by排序多列时 如果第一列没有相同值 则不会对第二列排序
2.在group by 中使用 with rollup 在所查询的分组之后增加一条记录，增加总和和统计数量

show engines; 查看当前数据库支持的存储引擎
show variables like '%storage_engine%';  查看你当前默认的数据库引擎
在创建表的时候可以使用ENGINE指定引擎 engine = Innodb default charset=gbk

支持的数据库引擎包括 myISAM InnoDB,BDB,NDB,CSV等.... 其中innoDB和BDB提供事务安全表，其他引擎都是非事务安全表
mysql 默认引擎5.5之前myISAM  >=5.5之后默认的是InnoDB

MyISAM

InnoDB

二分查找法

二叉查找树和二叉平衡树

B+Tree

哈希索引

常用的存储引擎最每个表最多支持16个索引，总索引长度为256个字节
myISAM和innoDB 默认创建的都是B+tree索引

1.最适合的做引列是 where 后面的列 而不是查询中的列
2.唯一索引，索引列基数越大 效果越好 例如：生日列每个人的生日不同很容易区分开 但是性别对于唯一所以就不好了
3.使用段索引  例如varchar(200) 前10到20个字符唯一 就可以对
4.索引不是越多越好，一个表中有大量的索引 会占用空间 而且insert delete update会影响性能 因为表数据更改时索引也会调整
5.尽量避免对update操作很多的表 进行增加很多索引

普通索引和唯一索引

全文索引

1.可以使用EXPLAIN查看索引是否在使用
2.show index from table查看索引

1.以%开口的like查询不能使用B+Tree索引
2.数据类型出现隐式转换的时候不会命中索引 例如：name是字符串类型的 where name=1是不会命中索引的 只有name='1'才可以
3.复合索引不满足左前缀条件下 不能命中索引 例如：索引中（a,b,c） b，或者bc都是不能命中索引
4.mysql使用索引比全表扫描更慢的时候 不会使用索引（索引优化器自行选择）
5.or条件 如果or前面的条件带有索引后边的没有索引 则会全表扫描 不使用索引。 
6.不要在列中运算
7.不使用NOT IN <>操作 NOT EXISTS代替NOT IN，id<>3则可使用id>3 or id<3来代替。

1.show status 了解sql的执行效率 主要看下面的参数：

  com_select  执行select查询操作每次加1 
  com_update 执行update次数
  com_inert    执行insert次数 批量insert只加1 
  com_delete 执行删除次数
  这个命令可以查看所有的状态（事务状态，数据库状态）并且根据状态可以查看出是依查询为主还是以更新为主
2.通过慢查询查询那些执行效率低的sql 但是不能定位问题 需要使用show processlist 查看当前进城 线程状态，是否锁表等
3.通过EXPIAIN sql语句分析执行计划
4.通过show profile分析sql