Java高阶知识体系总结（一）_java知识体系

Java高阶知识体系总结

1.Java 基础

Java类设计的原则就是内聚性，一致性和封装性是Java设计的基本原则
1.1 Java基础理论
Java基础理论知识
1.2继承的优缺点
优点 ：
新的实现很容易，因为大部分是继承而来的，很容易修改和扩展已有的实现
缺点 ：
1）打破了封装，因为基类向子类暴露了实现细节 。
2）白盒重用，因为基类的内部细节通常对子类是可见的
3）当父类的实现改变时可能要相应的对子类做出改变 。
4）不能在运行时改变由父类继承来的实现
由此可见，组合比继承具有更大的灵活性和更稳定的结构，一般情况下应该优先考虑组合。

只有当下列条件满足时才考虑使用继承：
1）子类是一种特殊的类型，而不只是父类的一个角色
2）子类的实例不需要变成另一个类的对象
3）子类扩展，而不是覆盖或者使父类的功能失效

2、JVM内存结构

2.1堆栈

栈stack和堆heapJAVA在程序运行时，在内存中划分5片空间进行数据的存储。
分别是：1：寄存器。2：本地方法区。3：方法区。4：栈。5：堆。

栈内存:基本数据类型、局部变量都是存放在栈内存中的，用完就消失。
堆内存:new创建的实例化对象及数组，是存放在堆内存中的，用完之后靠垃圾回收机制不定期自动消除。
栈：
1).函数中定义的基本类型变量，对象的引用变量都在函数的栈内存中分配。
2).栈内存特点，数数据一执行完毕，变量会立即释放，节约内存空间。
3).栈内存中的数据，没有默认初始化值，需要手动设置。
堆：
1).堆内存用来存放new创建的对象和数组。
2).堆内存中所有的实体都有内存地址值。
3).堆内存中的实体是用来封装数据的，这些数据都有默认初始化值。
4).堆内存中的实体不再被指向时，JVM启动垃圾回收机制，自动清除，这也是JAVA优于C++的表现之一
（C++中需要程序员手动清除）

3、Spring

3.1、简介

什么是spring，为什么要用spring?

1.Spring是一个分层的,一站式的轻量级开源框架
2.它致力于提供一种方法管理业务对象,使JavaEE的开发更方便快捷.
3.Spring不是仅仅专注于某一层的开发,而是贯穿应用于web层/业务层及持久层,
与struts2/SpringMVC/hibernate等框架进行无缝整合,
并对一些API(JDBC/JavaMail/远程调用等)进行了封装,降低了这些API的使用难度
4.继承Junit4,方便程序测试,@runwith(SpringJunit…)
5.对支持声明式事物管理@transational,只需通过配置就可以完成对事物的管理,无需动手编程
6.对AOP(Aspect Oriented Programming)编程的支持,Spring提供面向切面编程,方便实现对程序进行权限拦截/运行监控等功能
7.Spring 就是一个大工厂,可以将所有对象创建(IOC)和依赖关系维护(DI),交给Spring管理

3.2、IOC

IOC为InversionOfControl,控制反转是spring基于Java反射技术来实现的。IOC并不是spring或者面向对象的专用术语。
IOC 控制反转，是指对象实例化权利由spring容器来管理
实现原理: 工厂+反射+xml配置文件
底层是通过BeanFactory的子接口ApplicationContext接口的实现类ClassPathXmlApplicaitonContex从配置文件applicationContext.xml文件
中读取要创建的类名,再通过它的方法的getBean(“…”)反射的方式,创建出类,真正意义上达到解耦合的目的.
DI(dependency injection 依赖注入)
DI 依赖注入 在spring创建对象的过程中，对象所依赖的属性通过配置注入对象中。
实现原理:在spring框架负责创建Bean对象时，动态将依赖对象注入到Bean组件。

IoC中最基本的Java技术就是“反射”编程。通俗的说反射就是根据给出的类名（字符串）来生成对象。这种编程方式可以让对象在生成时才决定要生成哪一种对象。反射的应用是很广泛的，像Hibernate、Spring中都是用“反射”做为最基本的技术手段。
　　在过去，反射编程方式相对于正常的对象生成方式要慢10几倍，这也许也是当时为什么反射技术没有普遍应用开来的原因。但经SUN改良优化后，反射方式生成对象和通常对象生成方式，速度已经相差不大了（但依然有一倍以上的差距）。
IoC最大的好处是什么？因为把对象生成放在了XML里定义，所以当我们需要换一个实现子类将会变成很简单（一般这样的对象都是实现于某种接口的），只要修改XML就可以了，这样我们甚至可以实现对象的热插拔（有点像USB接口和SCSI硬盘了）。

3.3、AOP

面向切面编程，往往被定义为促使软件系统实现关注点的分离的技术。系统是由许多不同的组件所组成的，每一个组件各负责一块特定功能。除了实现自身核心功能之外，这些组件还经常承担着额外的职责。例如日志、事务管理和安全这样的核心服务经常融入到自身具有核心业务逻辑的组件中去。这些系统服务经常被称为横切关注点，因为它们会跨越系统的多个组件。
3.3.1一般用于日志记录，性能统计，安全控制，事务处理，异常处理等等。
3.3.2可以通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦,提高代码的灵活性和可扩展性，AOP可以说也是这种目标的一种实现。

3.4 spring事务传播特性

事务传播行为就是多个事务方法相互调用时，事务如何在这些方法间传播。
spring支持7种事务传播行为：

propagation_requierd：如果当前没有事务，就新建一个事务，如果已存在一个事务中，加入到这个事务中，这是最常见的选择。
propagation_supports：支持当前事务，如果没有当前事务，就以非事务方法执行。
propagation_mandatory：使用当前事务，如果没有当前事务，就抛出异常。
propagation_required_new：新建事务，如果当前存在事务，把当前事务挂起。
propagation_not_supported：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
propagation_never：以非事务方式执行操作，如果当前事务存在则抛出异常。
propagation_nested：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与propagation_required类似的操作

Spring 默认的事务传播行为是 PROPAGATION_REQUIRED，它适合于绝大多数的情况。

3.5 spring-boot

spring和springboot区别

项目配置:
Spring： 在Spring中，项目配置通常需要使用XML文件（如applicationContext.xml）或Java配置类来定义Bean、注入依赖等。
Spring Boot： Spring Boot采用约定大于配置的原则，通过默认的配置减少了开发者的工作量。它使用注解和自动配置，不需要繁琐的XML配置，大多数配置可以通过属性文件（如application.properties或application.yml）进行管理。
依赖管理：
Spring： 在Spring中，你需要手动管理项目的各种依赖，包括版本控制。
Spring Boot： Spring Boot使用了“Starter”依赖，这是一组预定义好的依赖集，可以快速集成常用的功能，开发者只需要在项目中引入相关的Starter依赖，而不需要手动配置每个依赖的版本。
内嵌服务器：
Spring： 在Spring中，你需要手动配置和集成Web服务器，如Tomcat或Jetty。
Spring Boot： Spring Boot内置了嵌入式的Web服务器（如Tomcat、Jetty或Undertow），默认情况下不需要任何额外的配置，你可以直接运行一个独立的JAR文件来启动应用。
开发体验：
Spring： 需要手动配置和管理很多细节，可能显得繁琐。
Spring Boot： 简化了配置和开发流程，使开发者更专注于业务逻辑的实现，提供了更好的开发体验。

4、Java线程

多线程能满足程序员编写高效率的程序来达到充分利用 CPU 的目的。
一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。
多线程是多任务的一种特别的形式，但多线程使用了更小的资源开销。
Java 提供了三种创建线程的方法：
通过实现 Runnable 接口；
通过继承 Thread 类本身；
通过 Callable 和 Future 创建线程。
有效利用多线程的关键是理解程序是并发执行而不是串行执行的。例如：程序中有两个子系统需要并发执行，这时候就需要利用多线程编程。
通过对多线程的使用，可以编写出非常高效的程序。不过请注意，如果你创建太多的线程，程序执行的效率实际上是降低了，而不是提升了。
请记住，上下文的切换开销也很重要，如果你创建了太多的线程，CPU 花费在上下文的切换的时间将多于执行程序的时间！
同步是多线程中的重要概念。同步的使用可以保证在多线程运行的环境中，程序不会产生设计之外的错误结果。同步的实现方式有两种，同步方法和同步块，这两种方式都要用到synchronized关键字。
eg:

/** * 用同步方法实现 * * @param money */
 public synchronized void save(int money) { 
 		account += money;
 } 
 /** * 用同步代码块实现 * * 
 @param money */ 
	 public void save0(int money) { synchronized (this) {
	 		 account += money;
   		}
    }
1
2
3
4
5
6
7
8
9
10

使用非依赖属性实现同步

4.1锁

Java中的锁y有 偏向锁、轻量级锁、自旋锁、重量级锁
锁从宏观上分类，分为悲观锁与乐观锁。
乐观锁：是一种乐观思想，即认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，采取在写时先读出当前版本号，然后加锁操作（比较跟上一次的版本号，如果一样则更新），如果失败则要重复读-比较-写的操作。
java中的乐观锁基本都是通过CAS操作实现的，CAS是一种更新的原子操作，比较当前值跟传入值是否一样，一样则更新，否则失败。
悲观锁：是就是悲观思想，即认为写多，遇到并发写的可能性高，每次去拿数据的时候都认为别人会修改，所以每次在读写数据的时候都会上锁，这样别人想读写这个数据就会block直到拿到锁。java中的悲观锁就是Synchronized,AQS框架下的锁则是先尝试cas乐观锁去获取锁，获取不到，才会转换为悲观锁，如RetreenLock。

4.1.2、Java中的锁

自旋锁:自旋锁原理非常简单，如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。
但是线程自旋是需要消耗cup的，说白了就是让cup在做无用功，如果一直获取不到锁，那线程也不能一直占用cup自旋做无用功，所以需要设定一个自旋等待的最大时间。
如果持有锁的线程执行的时间超过自旋等待的最大时间扔没有释放锁，就会导致其它争用锁的线程在最大等待时间内还是获取不到锁，这时争用线程会停止自旋进入阻塞状态。
偏向锁(Biased Locking)是Java6引入的一项多线程优化。
偏向锁，顾名思义，它会偏向于第一个访问锁的线程，如果在运行过程中，同步锁只有一个线程访问，不存在多线程争用的情况，则线程是不需要触发同步的，这种情况下，就会给线程加一个偏向锁。
如果在运行过程中，遇到了其他线程抢占锁，则持有偏向锁的线程会被挂起，JVM会消除它身上的偏向锁，将锁恢复到标准的轻量级锁。
轻量级锁：轻量级锁是由偏向所升级来的，偏向锁运行在一个线程进入同步块的情况下，当第二个线程加入锁争用的时候，偏向锁就会升级为轻量级锁；
重量级锁：synchronized会导致争用不到锁的线程进入阻塞状态，所以说它是java语言中一个重量级的同步操纵，被称为重量级锁，为了缓解上述性能问题，JVM从1.5开始，引入了轻量锁与偏向锁，默认启用了自旋锁，他们都属于乐观锁。

4.1.3、锁优化

减少锁的时间：不需要同步执行的代码，能不放在同步快里面执行就不要放在同步快内，可以让锁尽快释放；
减少锁的粒度：将物理上的一个锁，拆成逻辑上的多个锁，增加并行度，从而降低锁竞争。它的思想也是用空间来换时间；
锁粗化：大部分情况下我们是要让锁的粒度最小化，锁的粗化则是要增大锁的粒度;
在以下场景下需要粗化锁的粒度：
假如有一个循环，循环内的操作需要加锁，我们应该把锁放到循环外面，否则每次进出循环，都进出一次临界区，效率是非常差的；
使用读写锁：ReentrantReadWriteLock 是一个读写锁，读操作加读锁，可以并发读，写操作使用写锁，只能单线程写；
读写分离：CopyOnWriteArrayList 、CopyOnWriteArraySet
CopyOnWrite容器即写时复制的容器。通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以CopyOnWrite容器也是一种读写分离的思想，读和写不同的容器。
　CopyOnWrite并发容器用于读多写少的并发场景，因为，读的时候没有锁，但是对其进行更改的时候是会加锁的，否则会导致多个线程同时复制出多个副本，各自修改各自的；
使用CAS：如果需要同步的操作执行速度非常快，并且线程竞争并不激烈，这时候使用cas效率会更高，因为加锁会导致线程的上下文切换，如果上下文切换的耗时比同步操作本身更耗时，且线程对资源的竞争不激烈，使用volatiled+cas操作会是非常高效的选择；
消除缓存行的伪共享:除了我们在代码中使用的同步锁和jvm自己内置的同步锁外，还有一种隐藏的锁就是缓存行，它也被称为性能杀手。
在多核cup的处理器中，每个cup都有自己独占的一级缓存、二级缓存，甚至还有一个共享的三级缓存，为了提高性能，cpu读写数据是以缓存行为最小单元读写的；32位的cpu缓存行为32字节，64位cup的缓存行为64字节，这就导致了一些问题。

4.1.3、死锁

死锁是这样一种情形：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。
java 死锁产生的四个必要条件：
1、互斥使用，即当资源被一个线程使用(占有)时，别的线程不能使用
2、不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放。
3、请求和保持，即当资源请求者在请求其他的资源的同时保持对原有资源的占有。
4、循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个等待环路。
解决方式：对于无法成功获取的情况，一般就是重复尝试，或指定尝试的次数，也可以马上退出。

4.2、Threadlocal

ThreadLocal的作用是提供线程内的局部变量，这种变量在线程的生命周期内起作用，减少同一个线程内多个函数或者组件之间一些公共变量的传递的复杂度。
ThreadLocal在每个线程中对该变量会创建一个副本，即每个线程内部都会有一个该变量，且在线程内部任何地方都可以使用，线程之间互不影响，这样一来就不存在线程安全问题，也不会严重影响程序执行性能。
但是要注意，虽然ThreadLocal能够解决上面说的问题，但是由于在每个线程中都创建了副本，所以要考虑它对资源的消耗，比如内存的占用会比不使用ThreadLocal要大。

1）实际的通过ThreadLocal创建的副本是存储在每个线程自己的threadLocals中的；
2）为何threadLocals的类型ThreadLocalMap的键值为ThreadLocal对象，因为每个线程中可有多个threadLocal变量；
3）在进行get之前，必须先set，否则会报空指针异常；

4.3、Java对象的引用

包括:强引用，软引用，弱引用，虚引用
Java中提供这四种引用类型主要有两个目的：

第一是 可以让程序员通过代码的方式决定某些对象的生命周期；
第二是 有利于JVM进行垃圾回收。

强引用：是指创建一个对象并把这个对象赋给一个引用变量。
软引用：如果一个对象具有软引用，内存空间足够，垃圾回收器就不会回收它；
如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被 程序使用。软引用可用来实现内存敏感的高速缓存,比如网页缓存、图片缓存等。使用软引用能防止内存泄露，增强程序的健壮性。
SoftReference的特点是它的一个实例保存对一个Java对象的软引用， 该软引用的存在不妨碍垃圾收集线程对该Java对象的回收。
弱引用：WeakReference弱引用也是用来描述非必需对象的，当JVM进行垃圾回收时，无论内存是否充足，都会回收被弱引用关联的对象。在java中，用java.lang.ref.WeakReference类来表示。
虚引用：虚引用（PhantomReference）　虚引用和前面的软引用、弱引用不同，它并不影响对象的生命周期。在java中用java.lang.ref.PhantomReference类表示。如果一个对象与虚引用关联，则跟没有引用与之关联一样，在任何时候都可能被垃圾回收器回收

要注意的是，虚引用必须和引用队列关联使用，当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会把这个虚引用加入到与之 关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。如果程序发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。

4.4、ThreadPoolExecutor
ThreadPoolExecutor是线程池框架的一个核心类，通过对ThreadPoolExecutor，可以知道其对资源进行了复用，并非无限制的创建线程，可以有效的减少线程创建和切换的开销。
在ThreadPoolExecutor的内部，主要由阻塞队列BlockingQueue和抽象队列同步器AbstractQueuedSynchronizer对其提供支持，BlockingQueue接口有多种数据结构的实现，如LinkedBlockingQueue、ArrayBlockingQueue等。

corePoolSize:设置线程池的核心线程数，当添加新任务时，如果线程池中的线程数小于corePoolSize,则不管当前是否有线程闲置，都会创建一个新的线程来执行任务。
maximunPoolSize:是线程池中允许的最大的线程数
workQueue:用于存放排队的任务
keepAliveTime:是大于corePoolSize的线程闲置的超时时间
handler:用于在任务逸出、线程池关闭时的任务处理

线程池的线程增长策略为，当前线程数小于corePoolSize时，新增线程，当线程数=corePoolSize且corePoolSize时，只有在workQueue不能存放新的任务时创建新线程，超出的线程在闲置keepAliveTime后销毁。

5、JVM

JVM 是**Java虚拟机，是一种抽象化的计算机，通过在实际的计算机上仿真模拟各种计算机功能来实现的。Java虚拟机有自己完善的硬体架构，如处理器、堆栈、寄存器等，还具有相应的指令系统。Java虚拟机屏蔽了与具体操作系统平台相关的信息，使得Java程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。
Java源代码文件(.java)会被Java编译器编译为字节码文件(.class)，然后由JVM中的类加载器加载各个类的字节码文件，加载完毕之后，交由JVM执行引擎执行。
一个运行时的Java虚拟机实例的作用是：负责运行一个java程序。当启动一个Java程序时，一个虚拟机实例也就诞生了。当该程序关闭退出，这个虚拟机实例也就随之消亡。如果同一台计算机上同时运行三个Java程序，将得到三个Java虚拟机实例。每个Java程序都运行于它自己的Java虚拟机实例中。
Java虚拟机实例通过调用某个初始类的main()方法来运行一个Java程序。而这个main()方法必须是共有的(public)、静态的(static)、返回值为void，并且接受一个字符串数组作为参数**。任何拥有这样一个main()方法的类都可以作为Java程序运行的起点。

5.1、volatile

直接与主内存交互，保证可见性。避免指令重排序。
可见性是指的是线程访问变量是否是最新值。
局部变量不存在可见性问题，而共享内存就会有可见性问题。因为本地线程在创建的时候，会从主存中读取一个共享变量的副本，且修改也是修改副本，且并不是立即刷新到主存中去，那么其他线程并不会马上共享变量的修改。
因此，线程B修改共享变量后，线程A并不会马上知晓，就会出现上述死循环的问题。
解决共享变量可见性问题，需要用volatile关键字修饰。
可见性理解为：
1. 对volatile变量的写会立即刷新到主存
2. 对volatile变量的读会读主存中的新值
volatile是一个类型修饰符（type specifier），就像大家更熟悉的const一样，它是被设计用来修饰被不同线程访问和修改的变量。volatile的作用是作为指令关键字，确保本条指令不会因编译器的优化而省略，且要求每次直接读值。
volatile的变量是说这变量可能会被意想不到地改变，这样，编译器就不会去假设这个变量的值了。
一般说来，volatile用在如下的几个地方：
1、中断服务程序中修改的供其它程序检测的变量需要加volatile；
2、多任务环境下各任务间共享的标志应该加volatile；
3、存储器映射的硬件寄存器通常也要加volatile说明，因为每次对它的读写都可能有不同意义；
另外，以上这几种情况经常还要同时考虑数据的完整性（相互关联的几个标志读了一半被打断了重写），在1中可以通过关中断来实现，2 中可以禁止任务调度，3中则只能依靠硬件的良好设计了。
volatile关键字就是提示JVM：对于这个成员变量不能保存它的私有拷贝，而应直接与共享成员变量交互。
使用建议：在两个或者更多的线程访问的成员变量上使用volatile。当要访问的变量已在synchronized代码块中，或者为常量时，不必使用。
由于使用volatile屏蔽掉了JVM中必要的代码优化，所以在效率上比较低，因此一定在必要时才使用此关键字。

Java 语言包含两种内在的同步机制：同步块（或方法）和 volatile 变量。这两种机制的提出都是为了实现代码线程的安全性。其中 Volatile变量的同步性较差（但有时它更简单并且开销更低），而且其使用也更容易出错。

5.1、内存泄露

内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。

5.2、内存溢出

内存溢出（out of memory）通俗理解就是内存不够，通常在运行大型软件或游戏时，软件或游戏所需要的内存远远超出了你主机内安装的内存所承受大小，就叫内存溢出。此时软件或游戏就运行不了，系统会提示内存溢出，有时候会自动关闭软件，重启电脑或者软件后释放掉一部分内存又可以正常运行该软件。

5.3、JVM内存结构

JVM内存分为工作内存和主存。
工作内存：即java线程的本地内存，是单独给某个线程分配的，存储局部变量等，同时也会复制主存的共享变量作为本地的副本，目的是为了减少和主存通信的频率，提高效率。
主存：存储类成员变量等。

5.4、为什么要GC

GC是垃圾收集的意思，内存处理是编程人员容易出现问题的地方，忘记或者错误的内存回收会导致程序或系统的不稳定甚至崩溃，Java提供的GC功能可以自动监测对象是否超过作用域从而达到自动回收内存的目的，Java语言没有提供释放已分配内存的显示操作方法。Java程序员不用担心内存管理，因为垃圾收集器会自动进行管理。要请求垃圾收集，可以调用下面的方法之一:
System.gc() 或Runtime.getRuntime().gc() 。
垃圾回收可以有效的防止内存泄露，有效的使用可以使用的内存。垃圾回收器通常是作为一个单独的低优先级的线程运行，不可预知的情况下对内存堆中已经死亡的或者长时间没有使用的对象进行清除和回收，程序员不能实时的调用垃圾回收器对某个对象或所有对象进行垃圾回收。回收机制有分代复制垃圾回收、标记垃圾回收、增量垃圾回收等方式。
补充：标准的Java进程既有栈又有堆。栈保存了原始型局部变量，堆保存了要创建的对象。Java平台对堆内存回收和再利用的基本算法被称为标记和清除，但是Java对其进行了改进，采用“分代式垃圾收集”。这种方法会跟Java对象的生命周期将堆内存划分为不同的区域，在垃圾收集过程中，可能会将对象移动到不同区域：
伊甸园（Eden）：这是对象最初诞生的区域，并且对大多数对象来说，这里是它们唯一存在过的区域。

幸存者乐园（Survivor）：从伊甸园幸存下来的对象会被挪到这里。
终身颐养园（Tenured）：这是足够老的幸存对象的归宿。年轻代收集（Minor-GC）过程是不会触及这个地方的。当年轻代收集不能把对象放进终身颐养园时，就会触发一次完全收集（Major-GC），这里可能还会牵扯到压缩，以便为大对象腾出足够的空间
与垃圾回收相关的JVM参数：

-Xms / -Xmx --- 堆的初始大小 / 堆的最大大小
-Xmn --- 堆中年轻代的大小
-XX:-DisableExplicitGC --- 让System.gc()不产生任何作用
-XX:+PrintGCDetail --- 打印GC的细节
-XX:+PrintGCDateStamps --- 打印GC操作的时间戳
1
2
3
4
5

5.5、GC算法

我们一般讨论的垃圾回收主要针对Java堆内存中的新生代和老年代，也正因为新生代和老年代结构上的不同，所以产生了分代回收算法，即新生代的垃圾回收和老年代的垃圾回收采用的是不同的回收算法。针对新生代，主要采用复制算法，而针对老年代，通常采用标记-清除算法或者标记-整理算法来进行回收。
复制算法的思想是将内存分成大小相等的两块区域，每次使用其中的一块。当这一块的内存用完了，就将还存活的对象复制到另一块区域上，然后对该块进行内存回收。
这个算法实现简单，并且也相对高效，但是代价就是需要将牺牲一半的内存空间用于进行复制。有研究表明，新生代中的对象98%存活期很短，所以并不需要以1:1的比例来划分整个新生代，通常的做法是将新生代内存空间划分成一块较大的Eden区和两块较小的Survivor区，两块Survivor区域的大小保持一致。每次使用Eden和其中一块Survivor区，当回收的时候，将还存活的对象复制到另外一块Survivor空间上，最后清除Eden区和一开始使用的Survivor区。假如用于复制的Survivor区放不下存活的对象，那么会将对象存到老年代。
标记-清除(Mark-Sweep)算法分为两个阶段：
标记–>清除
在标记阶段将标记出需要回收的对象空间，然后在下一个阶段清除阶段里面，将这些标记出来的对象空间回收掉。这种算法有两个主要问题：一个是标记和清除的效率不高，另一个问题是在清理之后会产生大量不连续的内存碎片，这样会导致在分配大对象时候无法找到足够的连续内存而触发另一次垃圾收集动作。
标记-整理算法
标记-整理(Mark-Compact)算法有效预防了标记-清除算法中可能产生过多内存碎片的问题。在标记需要回收的对象以后，它会将所有存活的对象空间挪到一起，然后再执行清理。

5.6、JVM调优

JVM调优是指对Java虚拟机(JVM)的配置和参数进行优化，以提升Java应用程序的性能和效率。JVM调优的目标是通过合理配置和调整JVM的各种参数和设置，使得应用程序在运行时能够更高效地利用系统资源，提高执行速度、减少内存消耗，并且具备更好的可伸缩性和稳定性。

5.6.1 堆内存相关

常见的JVM调优内容包括：

1. 内存分配：根据应用程序的需求调整JVM的内存分配。如果应用程序需要处理大量数据，则可以增加JVM的堆内存和非堆内存。
2. 垃圾回收：通过选择不同的垃圾回收器、调整垃圾回收器的参数和设置合适的内存阈值等，可以提高垃圾回收的效率。
3. 线程管理：通过调整线程的数量、设置线程的优先级和使用线程池等方式，可以提高Java应用程序的并发性能。
4. 类加载：通过优化类的加载过程，可以提高应用程序的启动速度和响应性能。
5. 编译优化：JIT编译器可以将Java代码编译为本机代码，从而提高应用程序的执行速度。通过设置JIT编译器的参数和选择适当的编译器，可以提高编译器的性能和效率。
6. I/O优化：通过使用缓冲区、选择合适的I/O库、减少I/O操作次数等方式，可以提高I/O操作的效率。

调优步骤包括：

1. 熟悉业务场景，了解当前业务系统的要求，是吞吐量优先还是响应时间优先。
2. 选择合适的垃圾回收器组合。
3. 进行性能分析和监控，找出潜在的瓶颈和问题点。
4. 调优策略进行实际测试和验证。

参数主要有：内存相关、GC相关、GC日志相关；

5.6.2 堆内存相关

-Xms：用于指定Java应用使用的最小堆内存，如-Xms1024m表示将Java应用最小堆设置为1024M。
-Xmx：用于指定Java应用使用的最大堆内存，如-Xmx1024m表示将Java应用最大堆设置为1024m。过小的堆内存可能会造成程序抛出OOM异常，所以正常发布的应用应该明确指定这两个参数。并且，一般会选择将-Xms与-Xmx设置成一样大小，防止JVM动态调整堆内存容量对程序造成性能影响。
-Xmn：通过-Xmn可以设置堆内存中新生代的容量，以此达到间接控制老年代容量的作用，因为没有JVM参数可以直接控制老年代的容量。如-Xmn256m表示将新生代容量设置为256M。假如这个时候额外指定了-Xms1024m -Xmx1024m，那么老年代的容量为768M(1024-256=768)。
-XX:PermSize 与 -XX:MaxPermSize
-XX:PermSize和-XX:MaxPermSize分别用于设置永久代的容量和最大容量。如-XX:PermSize=64m -XX:MaxPermSize=128m表示将永久代的初始容量设置为64M，最大容量设置为128M。
-XX:SurvivorRatio：这个参数用于设置新生代中Eden区和Survivor(S0、S1)的容量比值。默认设置为-XX:SurvivorRatio=8表示Eden区与Survivor的容量比例为8:1:1。假设-Xmn256m -XX：Survivor=8，那么Eden区容量为204.8M(256M / 10 * 8)，S0和S1区的容量大小均为25.6M(256M / 10 * 1)。
1
2
3
4
5
6

5.6.2、GC收集器相关

XX:+UseSerialGC
虚拟机运行在client模式下的默认值，使用这个参数表示虚拟机将使用Serial + Serial Old收集器组合进行垃圾回收。
-XX:+UseSerialGC表示使用这个设置，而-XX:-UseSerialGC表示禁用这个设置。
-XX:+UseParNewGC
使用这个设置以后，虚拟机将使用ParNew + Serial Old收集器组合进行垃圾回收。
-XX:+UseConcMarkSweepGC
使用这个设置以后，虚拟机将使用ParNew + CMS + Serial Old的收集器组合进行垃圾回收。注意Serial Old收集器将作为CMS收集器出现Concurrent Mode Failure失败后的后备收集器来进行回收(将会整理内存碎片)。
-XX:+UseParallelGC
虚拟机运行在server模式下的默认值。使用这个设置，虚拟机将使用Parallel Scavenge + Serial Old(PS MarkSweep)的收集器组合进行垃圾回收。
-XX:+UseParallelOldGC
使用这个设置以后，虚拟机将使用Parallel Scavengen + Parallel Old的收集器组合进行垃圾回收。
-XX:PretenureSizeThreshold
设置直接晋升到老年代的对象大小，大于这个参数的对象将直接在老年代分配，而不是在新生代分配。注意这个值只能设置为字节，如-XX:PretenureSizeThreshold=3145728表示超过3M的对象将直接在老年代分配。
-XX:MaxTenuringThreshold
1
2
3
4
5
6
7
8
9
10
11
12
13
14

设置晋升到老年代的对象年龄。每个对象在坚持过一次Minor GC之后，年龄就会加1，当超过这个值时就进入老年代。

默认设置为-XX:MaxTenuringThreshold=15。
-XX:ParellelGCThreads
设置并行GC时进行内存回收的线程数。只有当采用的垃圾回收器是采用多线程模式，包括ParNew、Parallel Scavenge、Parallel Old、CMS，这个参数的设置才会有效。
-XX:CMSInitiatingOccupancyFraction
设置CMS收集器在老年代空间被使用多少(百分比)后触发垃圾收集。默认设置-XX:CMSInitiatingOccupancyFraction=68表示老年代空间使用比例达到68%时触发CMS垃圾收集。仅当老年代收集器设置为CMS时候这个参数才有效。
-XX:+UseCMSCompactAtFullCollection
设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片整理。仅当老年代收集器设置为CMS时候这个参数才有效。
-XX:CMSFullGCsBeforeCompaction
设置CMS收集器在进行多少次垃圾收集后再进行一次内存碎片整理。如设置-XX:CMSFullGCsBeforeCompaction=2表示CMS收集器进行了2次垃圾收集之后，进行一次内存碎片整理。仅当老年代收集器设置为CMS时候这个参数才有效。
1
2
3
4
5
6
7
8
9

5.6.3、GC日志相关

-XX:+PrintGCDetails
表示输出GC的详细情况。
-XX:+PrintGCDateStamps
指定输出GC时的时间格式，比指定-XX:+PrintGCTimeStamps可读性更高。
-Xloggc
指定gc日志的存放位置。如-Xloggc:/var/log/myapp-gc.log表示将gc日志保存在磁盘/var/log/目录，文件名为myapp-gc.log。
1
2
3
4
5
6

5.7、查看内存使用情况

命令：top
PID：进程的ID
　　USER：进程所有者
　　PR：进程的优先级别，越小越优先被执行
　　NInice：值
　　VIRT：进程占用的虚拟内存
　　RES：进程占用的物理内存
　　SHR：进程使用的共享内存
　　S：进程的状态。S表示休眠，R表示正在运行，Z表示僵死状态，N表示该进程优先值为负数
　　%CPU：进程占用CPU的使用率
　　%MEM：进程使用的物理内存和总内存的百分比
　　TIME+：该进程启动后占用的总的CPU时间，即占用CPU使用时间的累加值。
　　COMMAND：进程启动命令名称
1
2
3
4
5
6
7
8
9
10
11
12
13

5.8、YGC、FGC

youngGC、FullGC
当年轻代收集不能把对象放进终身颐养园时，就会触发一次完全收集（Major-GC），这里可能还会牵扯到压缩，以便为大对象腾出足够的空间。

5.9、CPU过高、内存占用过高处理

6、面向对象设计

使用涉及模式 其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。**
设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解
使用设计模式的好处：

可以提高程序员的思维能力、编程能力和设计能力。
使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期。
使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。

6.1、面向对象设计原则

我们平时接触的23种设计模式就是以面向对象七大原则为基础进行设计的。所以对面向对象设计的七大原则的学习有助于提高我们的设计水平，使我们设计的软件系统有较高的可维护性和可复用性。

学习设计原则也是学习设计模式的基础。在我们的实际开发过程中，并不是一定要求所有代码都遵循设计原则，我们要综合考虑现阶段的人力、时间、成本、质量，不要刻意为了去追求完美去遵守设计原则，有时候为了追求设计原则，可能会造成过度设计的问题，使代码变得臃肿复杂，所以要在适当的场景去遵循设计原则，这就要体现出我们在设计时如何去取舍，合理运用设计原则会帮助我们设计出更加优雅的代码结构。

七大原则本质上指导了两件事情:一个类该如何设计，两个类关系该如何设计。

对于一个类的职责要单一，类的变化点要尽可能少和开闭原则，即软件实体对扩展是开放的，但对 修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能。这两个原则使得一个类满足高内聚。
对于2个类关系该如何设计，从策略上来讲，最鼓励我们去遵循的首先是迪米特法则，即两个类尽量不要发生关系，要尽量少的去发生关系；如果非要发生关系，鼓励遵循依赖倒置原则，要依赖抽象，和抽象发生关系而不是具体的类发生关系，即要针对抽象层编程，而不要针对具体类编程；接着就是，若发生依赖关系，要注意接口隔离原则，即，使用多个专门的接口来取代一个统一的接口，要依赖也仅仅依赖自己需要的服务；如果现在有复用的需要，应该优先使用关联关系而不是继承，即遵循合成复用原则；如果关联关系满足不了要求，非要用继承，那么此时就应该遵循里氏替换原则，即所有引用基类（父类）的地方必须能透明地使用其子类的对象。迪米特法则、依赖倒置原则、接口最小隔离原则、合成复用原则和里氏替换原则使得类之间满足松耦合。参考

6.、GoF的23种设计模式

单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
工厂方法（Factory Method）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。

代理（Proxy） 模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
适配器（Adapter） 模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
桥接（Bridge） 模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
装饰（Decorator） 模式：动态的给对象增加一些职责，即增加其额外的功能。
外观（Facade） 模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
享元（Flyweight） 模式：运用共享技术来有效地支持大量细粒度对象的复用。
组合（Composite） 模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
模板方法（TemplateMethod） 模式：定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
策略（Strategy） 模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
命令（Command） 模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
职责链（Chain of Responsibility） 模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
状态（State） 模式：允许一个对象在其内部状态发生改变时改变其行为能力。
建造者（Builder） 模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
中介者（Mediator） 模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
观察者（Observer） 模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
访问者（Visitor） 模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
迭代器（Iterator） 模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。

备忘录（Memento） 模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
解释器（Interpreter） 模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

6.3、其他

7、数据库

7.1、设计
7.1.1、3NF
数据库设计三大范式:
1nf,每列字段必须具有不可分割性;
2nf 每个属性必须和主键（主属性）相关;
3nf 每个属性必须与主属性直接相关或者说，属性不依赖于其他非主属性。

7.2、SQL
7.2.1、SQL执行顺序

	```
	sql执行顺序：
	(1)from
	(2) on
	(3) join
	(4) where
	(5) group by(开始使用select中的别名，后面的语句中都可以使用)
	(6) avg,sum....
	(7) having
	(8) select
	(9) distinct
	(10) order by
	```
1
2
3
4
5
6
7
8
9
10
11
12
13

select*
fromtableAjoinBonA.id=B.aId
wheresize>10
groupbysize
havingsum(xxx)>100
Orderbyyyy

7.3、索引

索引提供指向存储在表的指定列中的数据值的指针，然后根据您指定的排序顺序对这些指针排序。数据库使用索引以找到特定值，然后顺指针找到包含该值的行。这样可以使对应于表的SQL语句执行得更快，可快速访问数据库表中的特定信息。
当表中有大量记录时，若要对表进行查询，第一种搜索信息方式是全表搜索，是将所有记录一一取出，和查询条件进行一一对比，然后返回满足条件的记录，这样做会消耗大量数据库系统时间，并造成大量磁盘I/O操作；第二种就是在表中建立索引，然后在索引中找到符合查询条件的索引值，最后通过保存在索引中的ROWID（相当于页码）快速找到表中对应的记录。
7.3.1、什么时候建索引

（1）快速取数据；
（2）保证数据记录的唯一性；
（3）实现表与表之间的参照完整性；
（4）在使用ORDER by、group by子句进行数据检索时，利用索引可以减少排序和分组的时间。
当表中有大量记录时，若要对表进行查询，第一种搜索信息方式是全表搜索，是将所有记录一一取出，和查询条件进行一一对比，然后返回满足条件的记录，这样做会消耗大量数据库系统时间，并造成大量磁盘I/O操作；第二种就是在表中建立索引，然后在索引中找到符合查询条件的索引值，最后通过保存在索引中的ROWID（相当于页码）快速找到表中对应的记录。

索引是为了加速对表中数据行的检索而创建的一种分散的存储结构。
索引是针对表而建立的，它是由数据页面以外的索引页面组成的，每个索引页面中的行都会含有逻辑指针，以便加速检索物理数据。

7.3.2、索引实现算法，算法复杂度

动态查找树主要有：二叉查找树（Binary Search Tree），平衡二叉查找树（Balanced Binary Search Tree），红黑树(Red-Black Tree )，B-tree/B±tree/ B*-tree(B~Tree)。前三者是典型的二叉查找树结构。
其查找的时间复杂度O(log2N)与树的深度相关，那么降低树的深度自然会提高查找效率。

7.3.3、索引缺点与有点

优点：
1）大大加快数据的检索速度;
2）创建唯一性索引，保证数据库表中每一行数据的唯一性;
3）加速表和表之间的连接;
4）在使用分组和排序子句进行数据检索时，可以显著减少查询中分组和排序的时间。
缺点
1）索引需要占物理空间。
2）当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，降低了数据的维护速度。
根据数据库的功能，可以在数据库设计器中创建四种索引：普通索引、唯一索引、主键索引和聚集索引。

7.3.4、聚簇索引

也称为聚集索引，在聚集索引中，表中行的物理顺序与键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引， 即如果存在聚集索引，就不能再指定CLUSTERED 关键字。
是聚集索引的意思.CLUSTERED| NONCLUSTERED
指定为 PRIMARY KEY 或UNIQUE约束创建聚集或非聚集索引。PRIMARY KEY 约束默认为CLUSTERED；UNIQUE约束默认为 NONCLUSTERED。如果表中已存在聚集约束或索引，那么在 ALTER TABLE 中就不能指定 CLUSTERED。如果表中已存在聚集约束或索引，PRIMARY KEY 约束默认为 NONCLUSTERED
索引不是聚集索引，则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比，聚集索引通常提供更快的数据访问速度。聚集索引更适用于对很少对基表进行增删改操作的情况。。

7.3.5、什么SQL不走索引

你在Instance级别所用的是all_rows的方式
1)你的表的统计信息(最可能的原因)
2)你的表很小,上文提到过的,Oracle的优化器认为不值得走索引。

1、建立组合索引，但查询谓词并未使用组合索引的第一列，此处有一个INDEX SKIP SCAN概念。
2、在包含有null值的table列上建立索引，当时使用select count(*) from table时不会使用索引。
3、在索引列上使用函数时不会使用索引，如果一定要使用索引只能建立函数索引。
4、当被索引的列进行隐式的类型转换时不会使用索引
5、并不是所有情况使用索引都会加快查询速度，full scan table 有时会更快，尤其是当查询的数据量占整个
表的比重较大时，因为full scan table采用的是多块读，
当Oracle优化器没有选择使用索引时不要立即强制使用，要充分证明使用索引确实查询更快时再使用强制索引。
6、<>
7、like’’百分号在前
8、not in ,not exist.
1
2
3
4
5
6
7
8
9
10

7.4、分库、分表

7.4.1、什么时候分
据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务 的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。
分库分表有垂直切分和水平切分两种。
何谓垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立定义数据库workDB、商品数据库payDB、用户数据库userDB、日志数据库logDB等，分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。
7.4.2、会有什么问题
1）事务问题:在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；
如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
2）跨库跨表的join问题:在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。
3）额外的数据管理负担和数据运算压力:

7.5、事务

事务由事务开始(begin transaction)和事务结束(end transaction)之间执行的全体操作组成。

7.5.1、基本属性、传播属性

事务的四大属性ACID即事务的原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability.。
原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

7.5.2、隔离级别

事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化

① Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。
② Repeatable read (可重复读)：可避免脏读、不可重复读的发生。
③ Read committed (读已提交)：可避免脏读的发生。
④ Read uncommitted (读未提交)：最低级别，任何情况都无法保证。

脏读、不可重复读、幻象读：
脏读：指当一个事务正字访问数据，并且对数据进行了修改，而这种数据还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据还没有提交那么另外一个事务读取到的这个数据我们称之为脏数据。依据脏数据所做的操作肯能是不正确的。
不可重复读：指在一个事务内，多次读同一数据。在这个事务还没有执行结束，另外一个事务也访问该同一数据，那么在第一个事务中的两次读取数据之间，由于第二个事务的修改第一个事务两次读到的数据可能是不一样的，这样就发生了在一个事物内两次连续读到的数据是不一样的，这种情况被称为是不可重复读。
幻象读：一个事务先后读取一个范围的记录，但两次读取的纪录数不同，我们称之为幻象读（两次执行同一条 select 语句会出现不同的结果，第二次读会增加一数据行，并没有说这两次执行是在同一个事务中

spring事务传播特性：
事务传播行为就是多个事务方法相互调用时，事务如何在这些方法间传播。
spring支持7种事务传播行为：

propagation_requierd：如果当前没有事务，就新建一个事务，如果已存在一个事务中，加入到这个事务中，这是最常见的选择。
propagation_supports：支持当前事务，如果没有当前事务，就以非事务方法执行。
propagation_mandatory：使用当前事务，如果没有当前事务，就抛出异常。
propagation_required_new：新建事务，如果当前存在事务，把当前事务挂起。
propagation_not_supported：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
propagation_never：以非事务方式执行操作，如果当前事务存在则抛出异常。
propagation_nested：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与propagation_required类似的操作

Spring 默认的事务传播行为是 PROPAGATION_REQUIRED，它适合于绝大多数的情况。

7.5.3、分布式事务CAP和base理论

分布式系统对于数据的复制需求一般都来自于以下两个原因：
1）为了增加系统的可用性，以防止单点故障引起的系统不可用
2）提高系统的整体性能，通过负载均衡技术，能够让分布在不同地方的数据副本都能够为用户提供服务
数据复制在可用性和性能方面给分布式系统带来的巨大好处是不言而喻的，然而数据复制所带来的一致性挑战，也是每一个系统研发人员不得不面对的。

7.5.3.1、CAP

CAP理论：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中两项。
1）一致性
在分布式环境下，一致性是指数据在多个副本之间能否保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一直的状态。
对于一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据进行了更新操作并且更新成功后，却没有使得第二个节点上的数据得到相应的更新，于是在对第二个节点的数据进行读取操作时，获取的依然是老数据（或称为脏数据），这就是典型的分布式数据不一致的情况。在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都可以读取到其最新的值，那么这样的系统就被认为具有强一致性
2）可用性
可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。这里的重点是"有限时间内"和"返回结果"。
"有限时间内"是指，对于用户的一个操作请求，系统必须能够在指定的时间内返回对应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。另外，"有限的时间内"是指系统设计之初就设计好的运行指标，通常不同系统之间有很大的不同，无论如何，对于用户请求，系统必须存在一个合理的响应时间，否则用户便会对系统感到失望。
"返回结果"是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确地反映出队请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。
3）分区容错性
分区容错性约束了一个分布式系统具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
网络分区是指在分布式系统中，不同的节点分布在不同的子网络（机房或异地网络）中，由于一些特殊的原因导致这些子网络出现网络不连通的状况，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。需要注意的是，组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。

7.5.3.2、BASE

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
1、基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性----注意，这绝不等价于系统不可用。比如：
（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒
（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
2、软状态
软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
3、最终一致性
最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往又会结合在一起。

7.6、MySQL

7.6.1、存储引擎分类
（1）：MyISAM存储引擎（2）InnoDB存储引擎*,(3)：MEMORY存储引擎,（4）MERGE存储引擎
7.6.2、不同存储引擎特点
(1)：MyISAM存储引擎：不支持事务、也不支持外键，优势是访问速度快，对事务完整性没有 要求或者以select，insert为主的应用基本上可以用这个引擎来创建表
支持3种不同的存储格式，分别是：静态表；动态表；压缩表
静态表：表中的字段都是非变长字段，这样每个记录都是固定长度的，优点存储非常迅速，容易缓存，出现故障容易恢复；缺点是占用的空间通常比动态表多（因为存储时会按照列的宽度定义补足空格）ps：在取数据的时候，默认会把字段后面的空格去掉，如果不注意会把数据本身带的空格也会忽略。
动态表：记录不是固定长度的，这样存储的优点是占用的空间相对较少；缺点：频繁的更新、删除数据容易产生碎片，需要定期执行OPTIMIZE TABLE或者myisamchk-r命令来改善性能
压缩表：因为每个记录是被单独压缩的，所以只有非常小的访问开支
(2)InnoDB存储引擎:该存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比MyISAM引擎，写的处理效率会差一些，并且会占用更多的磁盘空间以保留数据和索引。
InnoDB存储引擎的特点：支持自动增长列，支持外键约束
(3)：MEMORY存储引擎:Memory存储引擎使用存在于内存中的内容来创建表。每个memory表只实际对应一个磁盘文件，格式是.frm。memory类型的表访问非常的快，因为它的数据是放在内存中的，并且默认使用HASH索引，但是一旦服务关闭，表中的数据就会丢失掉。
MEMORY存储引擎的表可以选择使用BTREE索引或者HASH索引，两种不同类型的索引有其不同的使用范围
Hash索引优点：
Hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。
Hash索引缺点： 那么不精确查找呢，也很明显，因为hash算法是基于等值计算的，所以对于“like”等范围查找hash索引无效，不支持；
Memory类型的存储引擎主要用于哪些内容变化不频繁的代码表，或者作为统计操作的中间结果表，便于高效地对中间结果进行分析并得到最终的统计结果，。对存储引擎为memory的表进行更新操作要谨慎，因为数据并没有实际写入到磁盘中，所以一定要对下次重新启动服务后如何获得这些修改后的数据有所考虑。
（4）MERGE存储引擎:Merge存储引擎是一组MyISAM表的组合，这些MyISAM表必须结构完全相同，merge表本身并没有数据，对merge类型的表可以进行查询，更新，删除操作，这些操作实际上是对内部的MyISAM表进行的。
7.6.3、行锁、表锁
mysql常用引擎有MYISAM和InnoDB，而InnoDB是mysql默认的引擎。MYISAM不支持行锁，而InnoDB支持行锁和表锁。

表锁：不会出现死锁，发生锁冲突几率高，并发低。
行锁：会出现死锁，发生锁冲突几率低，并发高。
锁冲突：例如说事务A将某几行上锁后，事务B又对其上锁，锁不能共存否则会出现锁冲突。（但是共享锁可以共存，共享锁和排它锁不能共存，排它锁和排他锁也不可以）
死锁：例如说两个事务，事务A锁住了1_{5行，同时事务B锁住了6}10行，此时事务A请求锁住6_{10行，就会阻塞直到事务B施放6}10行的锁，而随后事务B又请求锁住1_{5行，事务B也阻塞直到事务A释放1}5行的锁。死锁发生时，会产生Deadlock错误。
7.6.4、行锁的类型
行锁分 共享锁 和 排它锁。
共享锁又称：读锁。当一个事务对某几行上读锁时，允许其他事务对这几行进行读操作，但不允许其进行写操作，也不允许其他事务给这几行上排它锁，但允许上读锁。
排它锁又称：写锁。当一个事务对某几个上写锁时，不允许其他事务写，但允许读。更不允许其他事务给这几行上任何锁。包括写锁。
7.6.5、行锁的实现
1.行锁必须有索引才能实现，否则会自动锁全表，那么就不是行锁了。
2.两个事务不能锁同一个索引，例如：
1.事务A先执行：
2.selectmathfromzjewheremath>60forupdate;
3.事务B再执行：
4.selectmathfromzjewheremath<60forupdate；
5.这样的话，事务B是会阻塞的。如果事务B把math索引换成其他索引就不会阻塞，但注意，换成其他索引锁住的行不能和math索引锁住的行有重复。
7.6.5、导致MySQL数据库事务失效得几个原因

1. 存储引擎类型，myISAM不支持事务，但是它是高效得插入和查询存储引擎
2. Bean没有被spring管理
3. 方法不是public修饰得，

7.7 Oracle

Oracle的数据结构
oracle数据库是数据的无聊存储，包括数据文件ORA或DBF，控制文件，联机日志，参数文件，这里的数据库是一个操作系统只有一个库。可以看作是oracle就只有一个大数据库
实例：一个oracle实例有一系列的后台进程和内存结构组成，一个数据库可以有n个实例
数据文件dbf：数据文件是数据库的物理存储单位，数据库的数据是存储在表空间中的，真正是在某一个或多个数据文件中，而一个表空间
可以由一个或多个数据文件组成，一个数据文件只能属于一个表空间，一旦数据文件被加入到某个表空间后，就不能删除这个文件，如果
要删除文件，只能删除其所属的表空间才行
表空间：表空间是oracle对物理数据库上相关数据文件的逻辑映射，一个数据库可以被划分多个表空间，每个数据库至少有一个表空间
用户：用户是在实例下建立的，不同实例中可以建立相同的用户。
表的数据是由用户放入某一个表空间，而这个表空间会随机把这些表数据放到一个或多个数据文件

8、缓存

8.1、时机

remote dictionary server （远程数据服务） 内存高速缓存数据库 数据模型为 k－v 也就是redis 的一种最经常使用的数据类型 stringk－v 的算法时间复杂度 可是 0（1） 而mysql 的查询是基于表关联技术 ，这就是nosql的优势所在。

redis 和memcahe 的比较：

Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
Redis支持master-slave(主-从)模式应用，高可用的cache系统，支持集群服务器之间数据同步。
Redis支持数据持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
Redis单个value的最大限制是1GB，（k－v），memcached只能保存1MB的数据。（k：250kb v：1mb）
PS：1 从存储媒介来看，内存比磁盘的读取速度 hash查找是100w/s 的数量级
2 多路复用io (todo)

8.2、原因

那么为什么要使用类似redis这样的Nosql数据库呢？
1） 当数据量的总大小一个机器放不下时；
2） 数据索引一个机器的内存放不下时；
3） 访问量（读写混合）一个实例放不下时
单机时代，存储只用一台机器装mysql，如果每次存储成千上万条数据，这样很会导致mysql的性能很差，存储以及读取速度很慢，然后就演变成缓存+mysql+垂直拆分的方式。
Cache作为中间缓存时代，将所有的数据先保存到缓存中，然后再存入mysql中，减小数据库压力，提高效率。
但是当数据再次增加到又一个量级，上面的方式也不能满足需求，由于数据库的写入压力增加，缓存只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。
主从分离模式时代，在redis的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。

8.3、Redis

为什么选择Redis

1）Redis不仅仅支持简单的k/v类型的数据，同时还提供string、hash、list、set及zset(sorted set：有序集合)。
2）Redis支持master-slave(主-从)模式应用
3）Redis支持数据持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
4）Redis单个value的string类型是Redis最大限制是1GB，memcached只能保存1MB的数据
1
2
3
4

8.3.1 Redisd的几种数据淘汰策略

定时删除策略 : 在设置键的过期时间的同时，创建一个定时器，让定时器在键的过期时间来临时，立即执行对键的删除操作。
优点 : 对内存友好，保证过期键会尽可能快地被删除，并释放过期键所占用的内存。
缺点 : 对CPU时间不友好，占用太多CPU时间，影响服务器的响应时间和吞吐量。
惰性删除 策略 : 放任过期键不管，每次从键空间读写操作时，都检查键是否过期，如果过期，删除该键，如果没有过期，返回该键。
优点 : 对CPU时间友好，读写操作键时才对键进行过期检查，删除过期键的操作只会在非做不可的情况下进行。
缺点 : 对内存不友好，只要键不删除，就不会释放内存，浪费太多内存，有内存泄漏风险。
定期删除 策略 :
对定时删除策略和惰性删除策略的一种整合和折中。每隔一段时间执行一次定时删除，并通过限制删除操作执行的总时长和总频率来限制删除操作对CPU占用时间的影响。通过定期删除过期键，有效减少了因为过期键而带来的内存浪费。
难点：确定删除操作执行的总时长和总频率。执行太频繁，执行时间过长，就会退化成定时删除策略，影响客户端请求效率；执行得太少，执行时间太短，会演变为惰性删除，存在内存浪费的情况。
Redis服务器使用惰性删除和定期删除两种策略，通过配合使用，很好地在合理使用CPU时间和避免浪费内存之间取得平衡。

举例:
从过期键中随机选取 20 个 key
遍历这 20 个 key，并对过期的 key进行删除操作
如果过期的 key 比率超过25%，则重复步骤 1
同时，为了保证过期扫描不会出现循环过度，导致线程卡死现象，增加了扫描时间的上限，默认不会超过 25ms以及频次上线10次。

主动清理策略：
当前已用内存超过maxmemory限定时，触发主动清理策略。
清理时会根据用户配置的maxmemory-policy来做适当的清理。
主动清理策略主要有一下六种:

volatile-lru : 从已设置过期时间的数据集(server.db[i].expires)中挑选最近最少使用 的数据淘汰。
volatile-ttl : 从已设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数 据淘汰。
volatile-random : 从已设置过期时间的数据集(server.db[i].expires)中任意选择数据 淘汰。
allkeys-lru : 从数据集(server.db[i].dict)中挑选最近最少使用的数据淘汰。
allkeys-random : 从数据集(server.db[i].dict)中任意选择数据淘汰。
no-enviction : 禁止驱逐数据。

8.4、“缓存击穿”和“缓存雪崩”

缓存穿透：是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是，数据查询先进行缓存查询，如果key不存在或者key已经过期，再对数据库进行查询，并把查询到的对象，放进缓存。如果数据库查询对象为空，则不放进缓存。

避免方式一般会采用缓存空值的方式，也就是【代码流程】中第5步，如果从数据库查询的对象为空，也放入缓存，只是设定的缓存过期时间较短，比如设置为60秒。

缓存雪崩:是指在某一个时间段，缓存集中过期失效。
产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。

一般可以在时间加上一个随机因子。这样能尽可能分散缓存过期时间，而且，热门键值缓存时间长一些，冷门类目缓存时间短一些，也能节省缓存服务的资源。

缓存击穿：是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。

8.5、一致性Hash

CARP ：Common Access Redundancy Protocol共用地址冗余协议Common Access Redundancy Protocol，或简称 CARP 能够使多台主机共享同一 IP 地址。在某些配置中，这样做可以提高可用性，或实现负载均衡。这些主机也可以同时使用其他的不同的 IP 地址。
一致性哈希基本解决了在P2P环境中最为关键的问题——如何在动态的网络拓扑中分布存储和路由。每个节点仅需维护少量相邻节点的信息，并且在节点加入/退出系统时，仅有相关的少量节点参与到拓扑的维护中。所有这一切使得一致性哈希成为第一个实用的DHT算法。
但是一致性哈希的路由算法尚有不足之处。在查询过程中，查询消息要经过O(N)步(O(N)表示与N成正比关系，N代表系统内的节点总数)才能到达被查询的节点。不难想象，当系统规模非常大时，节点数量可能超过百万，这样的查询效率显然难以满足使用的需要。换个角度来看，即使用户能够忍受漫长的时延，查询过程中产生的大量消息也会给网络带来不必要的负荷。
DHT(Distributed Hash Table，分布式哈希表)类似Tracker的根据种子特征码返回种子信息的网络。DHT全称叫分布式哈希表(Distributed Hash Table)，是一种分布式存储方法。在不需要服务器的情况下，每个客户端负责一个小范围的路由，并负责存储一小部分数据，从而实现整个DHT网络的寻址和存储。新版BitComet允许同行连接DHT网络和Tracker，也就是说在完全不连上Tracker服务器的情况下，也可以很好的下载，因为它可以在DHT网络中寻找下载同一文件的其他用户。

9、MQ

9.1 MQ特性

1、顺序保证/先进先出
不能先进先出，都不能说是队列了。消息队列的顺序在入队的时候就基本已经确定了，一般是不需人工干预的。而且，最重要的是，数据是只有一条数据在使用中。 这也是MQ在诸多场景被使用的原因。
2、发布订阅/异步通信
发布订阅是一种很高效的处理方式，如果不发生阻塞，基本可以当做是同步操作。这种处理方式能非常有效的提升服务器利用率，这样的应用场景非常广泛。
3、持久化
持久化确保MQ的使用不只是一个部分场景的辅助工具，而是让MQ能像数据库一样存储核心的数据,消息中间件允许把数据持久化知道他们完全被处理。
4、分布式
在现在大流量、大数据的使用场景下，只支持单体应用的服务器软件基本是无法使用的，支持分布式的部署，才能被广泛使用。而且，MQ的定位就是一个高性能的中间件。
5、解耦
基于数据的接口层，不同的项目都实现这个接口，允许独立的修改或者扩展两边的处理过程，只要两边遵守相同的接口约束即可，从而达到解耦作用。
6、增加缓冲，避免突然大量业务访问的压力

9.2 Kafka、RabbitMQ、RocketMQ性能比较:

Kafka:是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache顶级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。
RabbitMQ:是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
RocketMQ:是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。

在服务端处理同步发送的性能上，Kafka>RocketMQ>RabbitMQ。

9.1、P2P
peer to peer
9.2、pub/sub
广播

10、网络

10.1、OSI模型（计算机网络分层）

顺序分别为：
7 应用层 6 表示层 5 会话层 4 传输层 3 网络层 2 数据链路层 1 物理层 。
OSI是一个开放性的通信系统互连参考模型，他是一个定义得非常好的协议规范。OSI模型有7层结构，每层都可以有几个子层。
OSI的7层从上到下分别是： 7 应用层 6 表示层 5 会话层 4 传输层 3 网络层 2 数据链路层 1 物理层 ；
其中高层（即7、6、5、4层）定义了应用程序的功能，下面3层（即3、2、1层）主要面向通过网络的端到端的数据流。

10.2、DNS

DNS（Domain Name System，域名系统），万维网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过域名，最终得到该域名对应的IP地址的过程叫做域名解析（或主机名解析）。
DNS协议运行在UDP协议之上，使用端口号53。在RFC文档中RFC 2181对DNS有规范说明，RFC 2136对DNS的动态更新进行说明，RFC 2308对DNS查询的反向缓存进行说明。

10.3、Http协议状态码

200 OK 服务器成功处理了请求（这个是我们见到最多的）
301/302 Moved Permanently（重定向）请求的URL已移走。Response中应该包含一个Location URL, 说明资源现在所处的位置
304 Not Modified（未修改）客户的缓存资源是最新的， 要客户端使用缓存
404 Not Found 未找到资源
501 Internal Server Error服务器遇到一个错误，使其无法对请求提供服务

10.4、TCP、UDP

TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议。其中TCP提供IP环境下的数据可靠传输，它提供的服务包括数据流传送、可靠性、有效流控、全双工操作和多路复用。通过面向连接、端到端和可靠的数据包发送。通俗说，它是事先为所发送的数据开辟出连接好的通道，然后再进行数据发送；而UDP则不为IP提供可靠性、流控或差错恢复功能。一般来说，TCP对应的是可靠性要求高的应用，而UDP对应的则是可靠性要求低、传输经济的应用。

TCP支持的应用协议主要有：Telnet、FTP、SMTP等；
UDP支持的应用层协议主要有：NFS（网络文件系统）、SNMP（简单网络管理协议）、DNS（主域名称系统）、TFTP（通用文件传输协议）等。

10.5、IP

网络之间互连的协议（IP）是Internet Protocol的外语缩写， [1] 中文缩写为“网协”。
网络之间互连的协议也就是为计算机网络相互连接进行通信而设计的协议。在因特网中，它是能使连接到网上的所有计算机网络实现相互通信的一套规则，规定了计算机在因特网上进行通信时应当遵守的规则。任何厂家生产的计算机系统，只要遵守IP协议就可以与因特网互连互通。IP地址具有唯一性，根据用户性质的不同，可以分为5类。另外，IP还有进入防护，知识产权，指针寄存器等含义。

10.6、https

10.6.1 http与https的区别

超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息。HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此HTTP协议不适合传输一些敏感信息，比如信用卡号、密码等。
为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS。为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。
HTTPS和HTTP的区别主要为以下四点：

一、https协议需要到ca申请证书，一般免费证书很少，需要交费。
二、http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
三、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
四、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

10.6.2、https的通信原理

客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤：

　（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。
　（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
　（3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。
　（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
　（5）Web服务器利用自己的私钥解密出会话密钥。
　（6）Web服务器利用会话密钥加密与客户端之间的通信。

10.6.3、https的四次握手：

1、客户端请求建立SSL链接，并向服务端发送一个随机数–Client random和客户端支持的加密方法，比如RSA公钥加密，此时是明文传输。

2、服务端回复一种客户端支持的加密方法、一个随机数–Server random、授信的服务器证书和非对称加密的公钥。

3.客户端收到服务端的回复后利用服务端的公钥，加上新的随机数–Premaster secret 通过服务端下发的公钥及加密方法进行加密，发送给服务器。

4、服务端收到客户端的回复，利用已知的加解密方式进行解密，同时利用Client random、Server random和Premaster secret通过一定的算法生成HTTP链接数据传输的对称加密key – session key。

11、IO与NIO

一个IO操作可以分为两个部分：发出请求、结果完成。如果从发出请求到结果返回，一直Block，那就是Blocking IO；如果发出请求就可以返回（结果完成不考虑），就是non-blocking IO；如果发出请求就返回，结果返回是Block在select或者poll上的，则其只能称为IO multiplexing；如果发出请求就返回，结果返回通过Call Back的方式被处理，就是AIO。
11.1、NIO和IO的主要区别：
1）IO是面向流的，NIO是面向缓冲区的
2）阻塞与非阻塞IO：
这意味着，当一个线程调用read() 或 write()时，该线程被阻塞，直到有一些数据被读取，或数据完全写入。该线程在此期间不能再干任何事情了。Java NIO的非阻塞模式，使一个线程从某通道发送请求读取数据，但是它仅能得到目前可用的数据，如果目前没有数据可用时，就什么都不会获取，而不是保持线程阻塞，所以直至数据变的可以读取之前，该线程可以继续做其他的事情。 非阻塞写也是如此。一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。 线程通常将非阻塞IO的空闲时间用于在其它通道上执行IO操作，所以一个单独的线程现在可以管理多个输入和输出通道（channel）。
3）选择器（Selectors）
Java NIO的选择器允许一个单独的线程来监视多个输入通道，你可以注册多个通道使用一个选择器，然后使用一个单独的线程来“选择”通道：这些通道里已经有可以处理的输入，或者选择已准备写入的通道。这种选择机制，使得一个单独的线程很容易来管理多个通道。

12、 Web服务

Web服务器的工作原理并不复杂，一般可分成如下4个步骤：连接过程、请求过程、应答过程以及关闭连接。下面对这4个步骤作一简单的介绍。连接过程就是Web服务器和其浏览器之间所建立起来的一种连接。查看连接过程是否实现，用户可以找到和打开socket这个虚拟文件，这个文件的建立意味着连接过程这一步骤已经成功建立。请求过程就是Web的浏览器运用socket这个文件向其服务器而提出各种请求。应答过程就是运用HTTP协议把在请求过程中所提出来的请求传输到Web的服务器，进而实施任务处理，然后运用HTTP协议把任务处理的结果传输到Web的浏览器，同时在Web的浏览器上面展示上述所请求之界面。关闭连接就是当上一个步骤–应答过程完成以后，Web服务器和其浏览器之间断开连接之过程。Web服务器上述4个步骤环环相扣、紧密相联，逻辑性比较强，可以支持多个进程、多个线程以及多个进程与多个线程相混合的技术。

13、幂等性

幂等操作的特点是人一次或者多次执行产生的影响均与一次执行的影响相同。
幂等函数和幂等方法实质使用了相同的参数重复执行。
在很多场景中，我们可以使用分布式事务、分布式锁等来保证一个方法在同一时间内只能被同一个线程执行，从而保证他的幂等性。

分布式锁通常有以下几种实现方案：
基于数据库实现分布式锁
基于缓存（redis）实现分布式锁
给予zookeeper实现分布式锁

14 RPC（远程过程调用）

远程过程调用
注册中心中任意一台机器宕机之后，可以切换到另一台主机上。如果所有的主机都宕机了，还可以依赖本地缓存进行通信