答：

1、面向人群不同：

JDK是面向开发人员使用的SDK。

JRE是Java Runtime Enviroment是指Java的运行环境，是面向Java程序的使用者。

2、重要程度不同：

JRE的地位就象一台PC机一样，编写的Java程序必须要JRE才能运行。只要你的电脑安装了JRE，就可以正确运行Jav a应用程序。

3、安装位置不同：

如果安装JDK，电脑有两套JRE，一套位于 \jre 另外一套位于 C:\Program Files\Java\j2re1.4.1_01 目录下。

如果安装JRE，会在 C:\Program Files\Java 目录下安装唯一的一套JRE。

 

JRE是java运行时环境，包含了java虚拟机，java基础类库。是使用java语言编写的程序运行所需要的软件环境，是提供给想运行java程序的用户使用的。

　　JDK是java开发工具包，是程序员使用java语言编写java程序所需的开发工具包，是提供给程序员使用的

答：“==”是关系运算符，equals()是方法，同时他们的结果都返回布尔值；
“==”使用情况如下：
1) 基本类型，比较的是值
2) 引用类型，比较的是地址
3) 不能比较没有父子关系的两个对象
equals()方法使用如下：
1) 系统类一般已经覆盖了equals()，比较的是内容。
2) 用户自定义类如果没有覆盖equals()，将调用父类的equals （比如是Object），而Object的equals的比较是地址（return (this ==
obj);）
3) 用户自定义类需要覆盖父类的equals()

 

两个对象equals相等，则它们的hashcode必须相等，反之则不一定。

例子：String s1=“通话”； String s1=“重地”；

System.print
.out(s1.hashcode()+””+s2.hashcode());  1179395 1179395

System.print
.out()s1.equals(s2); false

 

答：final的作用随着所修饰的类型而不同：

  1. final修饰类中的属性或者变量：无论属性是基本类型还是引用类型，final所起的作用都是变量里面存放的“值”不能变
  2. final修饰类中的方法：可以被继承，但继承后不能被重写
  3. final修饰类：类不可以被继承

答：-1

　　计算方法：

  1.  
    1. 参数的小数点后第一位<5，运算结果为参数整数部分
    2. 参数的小数点后第一位>5，运算结果为参数整数部分绝对值+1，符号（即正负）不变
    3. 参数的 小数点后第一位=5，正数运算结果为整数部分+1，负数运算结果为整数部分

　　总结：大于五全部加，等于五正数加， 小于五全不加

答：不属于。
Java8种基础的数据类型：byte、short、char、int、long、float、double、boolean。

 

不是。String是一个对象，是java等编程语言的字符串。

 

关于字符串String中的intern方法，是当前的字符对象（通过new出来的对象）可以使用intern方法从常量池中获取，

如果常量池中不存在该字符串，那么就新建一个这样的字符串放到常量池中。

相同的：都可以用于两个字符串的比较

不同：1 equlas可以接受一个object类型参数，而compareTo只能接收一个string参数 2equlas返回参数为boolean 而compareTo返回参数是int类型

 

答：String、StringBuffer、StringBuilder

　　区别：String是不可变的对象，对每次对String类型的改变时都会生成一个新的对象，StringBuffer和StringBuilder是可以改变对象的。

　　　　　对于操作效率：StringBuilder
> StringBuffer > String

　　　　　对于线程安全：StringBuffer 是线程安全，可用于多线程；StringBuilder 是非线程安全，用于单线程

　　　　　不频繁的字符串操作使用 String。反之，StringBuffer 和 StringBuilder 都优于String

String用final修饰的好处：高效安全

 

答：不一样，因为他们不是同一个对象。

解释：String str=”i”;

这句话的意思是把“i”这个值在内存中的地址赋给str,如果再有String str3=”i”；那么这句话的操作也是把“i”这个值在内存中的地址赋给str3,这两个引用的是同一个地址值，他们两个共享同一个内存。

而String str2 = new String(“i”);

则是将new String(“i”);的对象地址赋给str2，需要注意的是这句话是新创建了一个对象。如果再有String str4= new String(“i”);那么相当于又创建了一个新的对象，然后将对象的地址值赋给str4,虽然str2的值和str4的值是相同的，但是他们依然不是同一个对象了。

需要注意的是：String
str=”i”; 因为String 是final类型的，所以“i”应该是在常量池。

而new String(“i”);则是新建对象放到堆内存中。

答：有多种方法。我列出3种方法。

  1. 利用 StringBuffer 或 StringBuilder 的 reverse 成员方法:
  2. 利用 String 的 toCharArray 方法先将字符串转化为 char 类型数组，然后将各个字符进行重新拼接:

3.利用 String 的 CharAt 方法取出字符串中的各个字符:

第一种：

public class Main {

 

    public static void main(String[] args) {

       
String s1 = “asdfghjkl”;       
System.out.println(new Main().swapWords(s1));

 

    }

 

    public void swap(char[]
arr, int begin, int end) {

       
while (begin < end) {

           
char temp = arr[begin];

           
arr[begin] = arr[end];

           
arr[end] = temp;

           
begin++;

           
end–;

       
}

    }

 

    public String swapWords(String str) {

       
char[] arr = str.toCharArray();

       
swap(arr, 0, arr.length – 1);

       
int begin = 0;

       
for (int i = 1; i < arr.length; i++) {

           
if (arr[i] == \’ \’) {

                swap(arr, begin, i – 1);

                begin = i + 1;

           
}

       
}

       
return new String(arr);

    }

}

 

第二种：

  1.  
  2.  
  3.   
  4.   
  5.   
  6.   
  7.   
  8.   
  9.   
  10.   
  11.   
  12.   
  13.   
  14.   
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  public class Main {

 

    public static void main(String[] args) {

        String s1 = “asdfghjkl”;

        String[] s = s1.split(“”);

        List<String> list = list = Arrays.asList(s);

        Collections.reverse(list);

        System.out.println(list);

    }

}

 

第三种：

  1.  
  2.  public class Main {

 

    public static void main(String[] args) {

        String s1 = “asdfghjkl”;

        System.out.println(new StringBuilder(s1).reverse().toString());

    }

}

 

答：下面列举了20个常用方法。格式：返回类型  方法名  作用。

Stringbuffer

Stringbuilder

join  把字符串数组转为字符串

trim 去掉字符串首尾空格

1、和长度有关：

  • int length() 得到一个字符串的字符个数

2、和数组有关：

  • byte[] getByte() ) 将一个字符串转换成字节数组
  • char[] toCharArray() 将一个字符串转换成字符数组
  • String split(String) 将一个字符串按照指定内容劈开

3、和判断有关：

  • boolean equals() 判断两个字符串的内容是否一样
  • String  compareTo()  判断两个字符串的内容是否一样
  • boolean equalsIsIgnoreCase(String) 忽略太小写的比较两个字符串的内容是否一样
  • boolean contains(String) 判断一个字符串里面是否包含指定的内容
  • boolean startsWith(String) 判断一个字符串是否以指定的内容开头
  • boolean endsWith(String) 判断一个字符串是否以指定的内容结尾

4、和改变内容有关：

  • String toUpperCase() 将一个字符串全部转换成大写
  • String toLowerCase() 将一个字符串全部转换成小写
  • String replace(String,String) 将某个内容全部替换成指定内容
  • String replaceAll(String,String) 将某个内容全部替换成指定内容，支持正则
  • String repalceFirst(String,String) 将第一次出现的某个内容替换成指定的内容
  • String substring(int) 从指定下标开始一直截取到字符串的最后
  • String substring(int,int) 从下标x截取到下标y-1对应的元素
  • String trim() 去除一个字符串的前后空格

5、和位置有关：

  • char charAt(int) 得到指定下标位置对应的字符
  • int indexOf(String) 得到指定内容第一次出现的下标
  • int lastIndexOf(String) 得到指定内容最后一次出现的下标

答：抽象类中不一定要包含抽象(abstrace)方法。也就是了，抽象中可以没有抽象(abstract)方法。反之，类中含有抽象方法，那么类必须声明为抽象类。

答：

  1. 抽象类不能被实例
  2. 抽象类不能有构造函数，抽象方法也不能被声明为静态
  3. 抽象类可以有抽象方法
  4. 抽象类的抽象方法必须被非抽象子类继承

答：不能,抽象类是被用于继承的,final修饰代表不可修改、不可继承的

答：

  1. 抽象类是被子类继承，接口是被类实现
  2. 接口只能做方法申明，抽象类中可以做方法申明，也可以做方法实现
  3. 接口里定义的变量只能是公共的静态的常量，抽象类中的变量是普通变量
  4. 接口是设计的结果 ，抽象类是重构的结果

答：可以分4种。

  1. 字节输入流（InputStream）
  2. 字节输出流（OutputStream）
  3. 字符输入流（Reader）
  4. 字符输出流（Writer）

答：BIO：线程发起IO请求，不管内核是否准备好IO操作，从发起请求起，线程一直阻塞，直到操作完成。
NIO：线程发起IO请求，立即返回；内核在做好IO操作的准备之后，通过调用注册的回调函数通知线程做IO操作，线程开始阻塞，直到操作完成。
AIO：线程发起IO请求，立即返回；内存做好IO操作的准备之后，做IO操作，直到操作完成或者失败，通过调用注册的回调函数通知线程做IO操作完成或者失败。

BIO是一个连接一个线程。
NIO是一个请求一个线程。
AIO是一个有效请求一个线程。

BIO：同步并阻塞，服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销，当然可以通过线程池机制改善。
NIO：同步非阻塞，服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。
AIO：异步非阻塞，服务器实现模式为一个有效请求一个线程，客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理。
适用场景分析

BIO方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4以前的唯一选择，但程序直观简单易理解。
NIO方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂，JDK1.4开始支持。
AIO方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持。

 

 

答：创建：
createNewFile()在指定位置创建一个空文件，成功就返回true，如果已存在就不创建，然后返回false。
mkdir() 在指定位置创建一个单级文件夹。
mkdirs() 在指定位置创建一个多级文件夹。
renameTo(File dest)如果目标文件与源文件是在同一个路径下，那么renameTo的作用是重命名， 如果目标文件与源文件不是在同一个路径下，那么renameTo的作用就是剪切，而且还不能操作文件夹。

删除：
delete() 删除文件或者一个空文件夹，不能删除非空文件夹，马上删除文件，返回一个布尔值。
deleteOnExit()jvm退出时删除文件或者文件夹，用于删除临时文件，无返回值。
判断：
exists() 文件或文件夹是否存在。
isFile() 是否是一个文件，如果不存在，则始终为false。
isDirectory() 是否是一个目录，如果不存在，则始终为false。
isHidden() 是否是一个隐藏的文件或是否是隐藏的目录。
isAbsolute() 测试此抽象路径名是否为绝对路径名。
获取：
getName() 获取文件或文件夹的名称，不包含上级路径。
getAbsolutePath()获取文件的绝对路径，与文件是否存在没关系
length() 获取文件的大小（字节数），如果文件不存在则返回0L，如果是文件夹也返回0L。
getParent() 返回此抽象路径名父目录的路径名字符串；如果此路径名没有指定父目录，则返回null。
lastModified()获取最后一次被修改的时间。

文件夹相关：
static File[] listRoots()列出所有的根目录（Window中就是所有系统的盘符）
list() 返回目录下的文件或者目录名，包含隐藏文件。对于文件这样操作会返回null。
listFiles() 返回目录下的文件或者目录对象（File类实例），包含隐藏文件。对于文件这样操作会返回null。
list(FilenameFilter filter)返回指定当前目录中符合过滤条件的子文件或子目录。对于文件这样操作会返回null。
listFiles(FilenameFilter filter)返回指定当前目录中符合过滤条件的子文件或子目录。对于文件这样操作会返回null。

 

1.使用new创建对象 2.使用Class类的newInstance方法

3.clone方法需要实现Cloneable接口4.采用序列化机制要实现实现Serializable接口

 

 

1对于所有对象来说，x.clone()!=x应当返回true，因为克隆对象与原对象不是同一个对象；

2对于所有对象来说，x.clone().getClass()==x.getClass()应当返回 true，因为克隆对象与原对象的类型是一样的；

3对于所有对象来说，x.clone().equals(x) 应当返回 true，因为使用 equals 比较时，它们的值都是相同的。

如果是数组类型，我们可以直接使用 Arrays.copyOf() 来实现克隆 我们在修改克隆对象的第一个元素之后，原型对象的第一个元素也跟着被修改了，这说明 Arrays.copyOf() 其实是一个浅克隆。 数组本身就是引用类型，因此在使用Arrays.copyOf()其实只是把引用地址复制了一份给克隆对象，如果修改了它的引用对象，那么指向它的（引用地址）所有对象都会发生改变，因此看到的结果是，修改了克隆对象的第一个元素，原型对象也跟着被修改了。

所有对象都实现克隆方法；

通过构造方法实现深克隆；

使用JDK自带的字节流实现深克隆；

使用第三方工具实现深克隆，比如ApacheCommonsLang；

使用 JSON 工具类实现深克隆，比如 Gson、FastJSON 等。

 

因为clone()方法语义的特殊性，因此最好能有JVM的直接支持，既然要JVM直接支持，就要找一个API来把这个方法暴露出来才行，最直接的做法就是把它放入到一个所有类的基类 Object 中，这样所有类就可以很方便地调用到了。

答：数组,String,java.util下的集合容器

List:存放有序,列表存储,元素65可重复

Set:无序,元素不可重复

Map:无序,元素可重复

 

解释：Java容器：

数组,String,java.util下的集合容器

数组长度限制为
Integer.Integer.MAX_VALUE;

String的长度限制:
底层是char 数组 长度 Integer.MAX_VALUE 线程安全的

 

List:存放有序,列表存储,元素可重复

Set:无序,元素不可重复

Map:无序,元素可重复

分别从以下点进行对比 
1.有无顺序 
2.元素是否可重复 
3.可存放元素数量 
4.底层实现 
5.线程安全性 
6.通常用来做什么 
7.优点，特性 
8.线程安全框架包 
9.在现有哪些框架上用到了这些集合

Set底层HashMap实现

HashMap底层用数组+链表实现

LinkedHashMap,TreeHashMap底层用额外的链表和树进行维护

HashMap的线程安全包:ConcurrentHashMap

ConcurrentHashMap1.7和1.8的区别

JUC包各种知识点。

 

答：Collection是集合类的顶级接口，其派生了两个子接口 Set 和 List。

　　Collections则是集合类的一个工具类/帮助类，其中提供了一系列静态方法，用于对集合中元素进行排序、搜索以及线程安全等各种操作。

总的来说：Collection是一个接口，而Collections是个类。

答：

  • List：
    • 可以允许重复对象
    • 可以插入多个null元素
    • 是一个有序容器
  • Set：
    • 不允许重复对象
    • 只允许一个null元素
    • 无序容器
  • Map:
    • Map不是Collection的子接口或实现类。Map是一个接口
    • Map 的每个Entry都特有两个对象，也就是一个键一个值，Map可能会持有相同的值对象但键对象必须是唯一的
    • Map里可以拥有随意个null值但最多只能有一个null键

答：

相同：

HashMap和Hashtable都是用hash算法来决定其元素的存储

异同：

1、继承的父类不同

    Hashtable继承自Dictionary类，而HashMap继承自AbstractMap类。但二者都实现了Map接口。

2、从线程安全角度：

①Hashtable是线程安全的，它的每个方法中都加入了Synchronize方法。在多线程并发的环境下，可以直接使用Hashtable，不需要自己为它的方法实现同步

②HashMap是线程不安全的，在多线程并发的环境下，可能会产生死锁等问题。使用HashMap时就必须要自己增加同步处理，

 虽然HashMap不是线程安全的，但是它的效率会比Hashtable要好很多。

3、从数据结构角度:

①Hashtable底层数组+链表实现。每个元素是一个key-value键值对。但无论key还是value都不能为null

②HashMap底层数组+链表实现。每个元素是一个key-value键值对。且可以接受null(HashMap可以接受为null的键(key)和值(value)

答：对于在 Map 中插入、删除、定位一个元素这类操作，HashMap 是最好的选择，因为相对而言 HashMap 的插入会更快，但如果你要对一个 key 集合进行有序的遍历，那 TreeMap 是更好的选择。

答：jdk1.8 HashMap使用数组加链表加红黑树实现。当链表大于 8 时，并且容量大于 64 时 链表结构会转换成红黑树结构 每个数组中储存着链表。当使用put方法储存key-value键值对时，会先调用key的hashCode方法，得到此key经特定哈希运算后的值，然后将此值通过其他运算（？）得到一个值，将这个值与(length-1)做或操作(&)，相当于对数组长度做取余操作。最终得到一个值作为此key在数组中的索引值，然后将key-value键值对储存进去。通过这种方法将储存的不同key-value键值对“散列”到数组的不同位置。

在储存的时候，如果索引位置尚无元素，那么直接储存。如果有元素，那么就调用此key的equals方法与原有的元素的Key进行比较。如果返回true，说明在这个equals定义的规则上，这两个Key相同，那么将原有的key保留，用新的value代替原来的value。如果返回false，那么就说明这两个key在equals定义的规则下是不同元素，那么就与此链表的下一个结点进行比较，知道最后一个结点都没有相同元素，再下一个是null的时候，就用头插法将此key-value添加到链表上。

HashMap对重复元素的处理方法是：key不变，value覆盖。

当使用get方法获取key对应的value时，会和储存key-value时用同样的方法，得到key在数组中的索引值，如果此索引值上没有元素，就返回null。如果此索引值上有元素，那么就拿此key的equals方法与此位置元素上的key进行比较，如果返回true。就返回此位置元素对应的value。如果返回false，就一直按链表往下比较，如果都是返回false，那么就返回null。

另外：HashMap在JDK1.8之后引入红黑树结构。HashMap是线程不安全的，线程安全的是CurrentHashMap，不过此集合在多线程下效率低。

JDK 1.8 之所以添加红黑树是因为一旦链表过长，会严重影响 HashMap 的性能，而红黑树具有快速增删改查的特点，这样就可以有效的解决链表过长时操作比较慢的问题。

答：首先，我们知道它是Set的一个实现，所以保证了当中没有重复的元素。

一方面Set中最重要的一个操作就是查找。而且通常我们会选择HashSet使用的是散列函数，

那么它当中的元素也就无需可寻，当中是允许元素为Null的。

1、它是基于HashMap实现的，默认构造函数是构建一个初始容量为16，负载因子为0.75的HashMap。封装了一个HashMap对象

来存储所有的集合元素，所有放入HashSet中的集合元素实际上由HashMap的key来保存，而HashMap的value则存储了

一个PRESENT,他是一个静态的Object对象。

2、当我们试图把某个类的对象当成HashMap的key，或试图将这个类的对象放入HashSet中保存时，重写该类的

equals方法与hashCode方法，而且这两个方法的返回值必须是一致的，当该类的两个hashCode返回值相同时，他们通过

 

equals1方法比较也应该返回true,通常来说，所有参与计算hashCode返回值的关键属性，都应该作为equals比较的标准。

3、HashSet的其他操作都是基于HashMap的。

 

 

答：• 数据结构实现：

ArrayList 是动态数组的数据结构实现，而
LinkedList 是双向链表的数据结构实现。

• 随机访问效率：

ArrayList 比 LinkedList 在随机访问的时候效率要高，

因为
LinkedList 是线性的数据存储方式，所以需要移动指针从前往后依次查找。

• 增加和删除效率：

在非首尾的增加和删除操作，LinkedList 要比 ArrayList 效率要高，

因为
ArrayList 增删操作要影响数组内的其他数据的下标。

• 综合来说：

在需要频繁读取集合中的元素时，更推荐使用 ArrayList，

而在插入和删除操作较多时，更推荐使用 LinkedList。

 

答：List转数组：toArray(arraylist.size()方法

数组转List：Arrays的asList(a)方法

 

答：List接口下一共实现了三个类：ArrayList，Vector和LinkedList

LinkedList主要保持数据的插入顺序的时候使用，采用链表结构；ArrayList，Vector都是使用的是长度可变的数组存储

一、ArrayList,Vector主要区别为以下几点：

（1）同步性：Vector是线程安全的，用synchronized实现线程安全，而ArrayList是线程不安全的，如果只有一个线程会访问到集合，那最好使用ArrayList，因为它不考虑线程安全，效率会高些；如果有多个线程会访问到集合，那最好是使用Vector，因为不需要我们再去考虑和编写线程安全的代码。

（2）数据容量增长：二者都有一个初始容量大小，采用线性连续存储空间，当存储的元素的个数超过了容量时，就需要增加二者的存储空间，Vector增长原来的一倍，ArrayList增加原来的0.5倍。

Vector：4个，默认长度为10

Vector多了一个public Vector(int initialCapacity, int capacityIncrement)构造器，可以设置容量增长，ArrayList是没有的。

答：Array 与 ArrayList 都是用来存储数据的集合。ArrayList 底层是使用数组实现的，但是ArrayList对数组进行了封装和功能扩展 

解释：1. Array类型的变量在声明的同时必须进行实例化(至少得初始化数组的大小)，而ArrayList可以只是先声明。
2. Array只能存储同构的对象，而ArrayList可以存储异构的对象。
同构的对象是指类型相同的对象，若声明为int[]的数组就只能存放整形数据,string[]只能存放字符型数据,但声明为object[]的数组除外。
而ArrayList可以存放任何不同类型的数据（因为它里面存放的都是被装箱了的Object型对象，实际上ArrayList内部就是使用”object[] _items;”这样一个私有字段来封装对象的）
3 在CLR托管对中的存放方式
Array是始终是连续存放的，而ArrayList的存放不一定连续。
4 初始化大小
Array对象的初始化必须只定指定大小，且创建后的数组大小是固定的，
而ArrayList的大小可以动态指定，其大小可以在初始化时指定，也可以不指定，也就是说该对象的空间可以任意增加。
5 Array不能够随意添加和删除其中的项，而ArrayList可以在任意位置插入和删除项。
Array和ArrayList的相似点
1 都具有索引(index),即可以通过index来直接获取和修改任意项。
2 他们所创建的对象都放在托管堆中。
3 都能够对自身进行枚举(因为都实现了IEnumerable接口)。

ArrayList的一些特性

ArrayList的capacity属性值会随ArrayList中的项的实际大小来发生改变

通过ArrayList类的TrimToResize()方法可以将ArrayList实例中的空项去除以压缩体积。

 

答：Queue 中 remove() 和 poll()都是用来从队列头部删除一个元素。
在队列元素为空的情况下，remove() 方法会抛出NoSuchElementException异常，poll() 方法只会返回 null 。

答：Vector：就比Arraylist多了个同步化机制（线程安全）。

Hashtable：就比Hashmap多了个线程安全。

ConcurrentHashMap:是一种高效但是线程安全的集合。

Stack：栈，也是线程安全的，继承于Vector。

 

答：Iterator 是可以遍历集合的对象，为各种容器提供了公共的操作接口，隔离对容器的遍历操作和底层实现，从而解耦。

缺点是增加新的集合类需要对应增加新的迭代器类，迭代器类与集合类成对增加。

 

答： Iterator it = Coll.iterator(); it.next(); it.hasNext();
it.remove();

迭代器的特点：
(1)ArrayIterator允许从PHP数组中创建一个迭代器，ArrayIterator可以直接跳过Iterator需要实现的5个方法，实现同样的功能。
(2)当ArrayIterator和IteratorAggregate一起工作的时候，直接免去Iterator创建方法的工作，只需要在实现IteratorAggregate的getIterator()方法的时候，返回一个ArrayIterator接口就好。
(3)IteratorAggregate的c语言实现代码，定义了抽象方法getIterator()，所以实现接口的时候，必须定义该方法。
(4)因为迭代器都实现了遍历接口（Traversable），所以当我们的HeaderCollection类实现了IteratorAggregate类之后，就可以直接使用foreach()遍历$this->_header中的每一个元素了。

 

答：我们需要知道的第一个则是：

（1）所属关系，ListIterator是一个Iterator的子类型。

（2）局限：只能应用于各种List类的访问。

（3）优势：Iterator只能向前移动，而ListIterator可以双向移动。

还可以产生相对于迭代器在列表中指向的当前位置的前一个和后一个元素的索引

nextIndex()、previousIndex()方法。

还可以通过set（）方法替换它访问过的最后一个元素。

还可以通过调用listIterator（）方法产生一个指向List开始处的ListIterator，当然也可以有参数，即指向索引为参数处的ListIterator。

（4）ListIterator 有 add() 方法，可以向 List 中添加对象，而 Iterator 不能。

答：可以使用 Collections. unmodifiableCollection(Collection
c) 方法来创建一个只读集合，这样改变集合的任何操作都会抛出 Java. lang.
UnsupportedOperationException 异常。

 

1，LinkedHashset : 保证元素添加的自然顺序
2，TreeSet : 保证元素的自然顺序

  • Java有两种方式实现多线程，第一个是继承Thread类，第二个是实现Runnable接口。他们之间的联系：
  • 1Thread类实现了Runable接口。
  • 2都需要重写里面Run方法。

无论你使用Runnable还是Thread，都有一个new Thread的过程，效果上最后都是new Thread，然后执行run方法。写法上的区别无非就是你是new Thead还是new你自定义的thread，如果你有复杂的线程操作需求，那就自定义Thread，如果只是简单的在子线程run一下任务，那就自己实现runnable，当然如果自己实现runnable的话可以多一个继承（自定义Thread必须继承Thread类，java单继承规定导致不能在继承别的了）。

同一个线程只能调用start()方法一次，多次调用会抛出java.lang.IllegalThreadStateException。启动一个线程，需要调用start()方法而不是run()方法。此时，当前线程会被添加到线程组中，进入就绪状态，等待线程调度器的调用，若获取到了资源，则能进入运行状态，run()方法只是线程体，即线程执行的内容，若没调用start()方法，run()方法只是一个普通的方法。

答：

  • 并发在单核和多核都可存在，就是同一时间有多个可以执行的进程。但是在单核中同一时刻只有一个进程获得CPU,虽然宏观上你认为多个进程都在进行
  • 并行是指同一时间多个进程在微观上都在真正的执行，这就只有在多核的情况下了

答：

  • 线程：是程序执行流的最小单元，是系统独立调度和分配CPU（独立运行）的基本单位
  • 进程：是资源分配的基本单位。一个进程包括多个线程

区别：地址空间、资源拥有

  1. 线程与资源分配无关，它属于某一个进程，并与进程内的其他线程一起共享进程的资源
  2. 每个进程都有自己一套独立的资源（数据），供其内的所有线程共享
  3. 不论是大小，开销线程要更“轻量级”
  4. 一个进程内的线程通信比进程之间的通信更快速，有效。（因为共享变量）

答：守护线程是个服务线程，服务于其他线程

当非守护线程停止，守护线程才停止。

典型案例：垃圾回收线程

答：

  • 继承Thread类创建线程
  • 实现Runnable接口创建线程
  • 通过Callable和Future创建线程

 

创建线程的三种方式的对比

采用实现Runnable、Callable接口的方式创见多线程时，优势是：

 线程类只是实现了Runnable接口或Callable接口，还可以继承其他类。

在这种方式下，多个线程可以共享同一个target对象，所以非常适合多个相同线程来处理同一份资源的情况，从而可以将CPU、代码和数据分开，形成清晰的模型，较好地体现了面向对象的思想。

劣势是：

编程稍微复杂，如果要访问当前线程，则必须使用Thread.currentThread()方法。

使用继承Thread类的方式创建多线程时优势是：

编写简单，如果需要访问当前线程，则无需使用Thread.currentThread()方法，直接使用this即可获得当前线程。

劣势是：

线程类已经继承了Thread类，所以不能再继承其他父类。

答：runnable 没有返回值，callable 可以拿到有返回值，callable 可以看作是 runnable 的补充。

扩展：

相同点：

1、两者都是接口；（废话）

2、两者都可用来编写多线程程序；

3、两者都需要调用Thread.start()启动线程；

不同点

1、两者最大的不同点是：实现Callable接口的任务线程能返回执行结果；而实现Runnable接口的任务线程不能返回结果；

2、Callable接口的call()方法允许抛出异常；而Runnable接口的run()方法的异常只能在内部消化，不能继续上抛；

注意点

Callable接口支持返回执行结果，此时需要调用FutureTask.get()方法实现，此方法会阻塞主线程直到获取‘将来’结果；当不调用此方法时，主线程不会阻塞！

Callable 类型的任务可以获取执行的返回值，而 Runnable 执行无返回值。

答：1.new  
新建状态  被创建出来，但尚未启动时的线程状态。

       2 RUNNABLE  就绪状态  表示运行状态 可能正在运行 或者是在排队等待操作系统 给分配cpu资源。

3
BLOCKED 阻塞等待锁的线程状态 表示处于阻塞状态的线程正在等待监视锁

4 WAITING 等待状态 一个处于等待状态的线程 正在等待另一个线程执行某个特定的动作

5 TIMED_WAITING 计时等待状态和waiting类似 只是多了超时时间(object
wait)(long timeout)和 Thread.join(long timeout))等这些方法时候 他才进入此状态

6    终止状态 表示线程已经执行完成

线程的工作模式是，首先先要创建线程并指定线程需要执行的业务方法，然后再调用线程的start()方法，此时线程就从NEW（新建）状态变成了RUNNABLE（就绪）状态，此时线程会判断要执行的方法中有没有synchronized同步代码块，如果有并且其他线程也在使用此锁，那么线程就会变为BLOCKED（阻塞等待）状态，当其他线程使用完此锁之后，线程会继续执行剩余的方法

当遇到Object.wait()或Thread.join()方法时，线程会变为WAITING（等待状态）状态，如果是带了超时时间的等待方法，那么线程会进入TIMED_WAITING（计时等待）状态，当有其他线程执行了 notify() 或 notifyAll() 方法之后，线程被唤醒继续执行剩余的业务方法，直到方法执行完成为止，此时整个线程的流程就执行完了

虽然BLOCKED和WAITING都有等待的含义，但二者有着本质的区别，首先它们状态形成的调用方法不同，其次BLOCKED可以理解为当前线程还处于活跃状态，只是在阻塞等待其他线程使用完某个锁资源；而WAITING则是因为自身调用了Object.wait()或着是Thread.join()又或者是LockSupport.park()而进入等待状态，只能等待其他线程执行某个特定的动作才能被继续唤醒，比如当线程因为调用了Object.wait()而进入WAITING状态之后，则需要等待另一个线程执行Object.notify()或 Object.notifyAll() 才能被唤醒。

在 Thread 源码中和线程优先级相关的属性有 3 个 //线程可以拥有的最小优先级为1;线程默认优先级为5; 线程可以拥有的最大优先级为10

线程的优先级可以理解为线程抢占CPU时间片的概率，优先级越高的线程优先执行的概率就越大，但并不能保证优先级高的线程一定先执行。在程序中我们可以通过Thread.setPriority()来设置优先级

（1）join()

在一个线程中调用 other.join() ，这时候当前线程会让出执行权给 other 线程，直到 other 线程执行完或者过了超时时间之后再继续执行当前线程，从源码中可以看出 join() 方法底层还是通过 wait() 方法来实现的。

（2）yield()

看 Thread 的源码可以知道 yield() 为本地方法，也就是说 yield() 是由 C 或 C++ 实现的，yield() 方法表示给线程调度器一个当前线程愿意出让 CPU 使用权的暗示，但是线程调度器可能会忽略这个暗示。

当我们把这段代码执行多次之后会发现，每次执行的结果都不相同，这是因为 yield() 执行非常不稳定，线程调度器不一定会采纳 yield() 出让 CPU 使用权的建议，从而导致了这样的结果。

 答：

对于sleep()方法，我们首先要知道该方法是属于Thread类中的。而wait()方法，则是属于Object类中的。

sleep()方法导致了程序暂停执行指定的时间，让出cpu该其他线程，但是他的监控状态依然保持者，当指定的时间到了又会自动恢复运行状态。

在调用sleep()方法的过程中，线程不会释放对象锁。

而当调用wait()方法的时候，线程会放弃对象锁，进入等待此对象的等待锁定池，只有针对此对象调用notify()方法后本线程才进入对象锁定池准备，获取对象锁进入运行状态。

答：

notify()方法随机唤醒对象等待池中的一个线程，进入锁池。

notifyAll()会将全部线程由等待池移到锁池，然后参与锁的竞争，竞争成功则继续执行，如果不成功则留在锁池等待锁被释放后再次参与竞争

答：

首先从 Thread 源码来看，start() 方法属于 Thread 自身的方法，并且使用了 synchronized 来保证线程安全，run() 方法为 Runnable 的抽象方法，必须由调用类重写此方法，重写的 run() 方法其实就是此线程要执行的业务方法

从执行的效果来说，start()方法可以开启多线程，让线程从NEW状态转换成RUNNABLE状态，而run()方法只是一个普通的方法。其次，它们可调用的次数不同，start() 方法不能被多次调用，否则会抛出 java.lang.IllegalStateException；而 run() 方法可以进行多次调用，因为它只是一个普通的方法而已。

线程池是为了避免线程频繁的创建和销毁带来的性能消耗，而建立的一种池化技术，它是把已创建的线程放入“池”中，当有任务来临时就可以重用已有的线程，无需等待创建的过程，这样就可以有效提高程序的响应速度

在阿里巴巴的《Java 开发手册》中是这样规定线程池的：

线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的读者更加明确线程池的运行规则，规避资源耗尽的风险。

第一：降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
第二：提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。
第三：提高线程的可管理性。线程是稀缺资源，如果无限制地创建，不仅会消耗系统资源，
还会降低系统的稳定性，使用线程池可以进行统一分配、调优和监控。

第1个参数：corePoolSize表示线程池的常驻核心线程数。如果设置为0，则表示在没有任何任务时，销毁线程池；如果大于0，即使没有任务时也会保证线程池的线程数量等于此值。但需要注意，此值如果设置的比较小，则会频繁的创建和销毁线程（创建和销毁的原因会在本课时的下半部分讲到）；如果设置的比较大，则会浪费系统资源，所以开发者需要根据自己的实际业务来调整此值。

第2个参数：maximumPoolSize表示线程池在任务最多时，最大可以创建的线程数。官方规定此值必须大于0，也必须大于等于corePoolSize，此值只有在任务比较多，且不能存放在任务队列时，才会用到。

第3个参数：keepAliveTime表示线程的存活时间，当线程池空闲时并且超过了此时间，多余的线程就会销毁，直到线程池中的线程数量销毁的等于corePoolSize为止，如果 maximumPoolSize 等于 corePoolSize，那么线程池在空闲的时候也不会销毁任何线程。

第 4 个参数：unit 表示存活时间的单位，它是配合 keepAliveTime 参数共同使用的。

第 5 个参数：workQueue 表示线程池执行的任务队列，当线程池的所有线程都在处理任务时，如果来了新任务就会缓存到此任务队列中排队等待执行。

第 6 个参数：threadFactory 表示线程的创建工厂，此参数一般用的比较少，我们通常在创建线程池时不指定此参数，它会使用默认的线程创建工厂的方法来创建线程。我们也可以自定义一个线程工厂，通过实现 ThreadFactory 接口来完成，这样就可以自定义线程的名称或线程执行的优先级了。

第7个参数：RejectedExecutionHandler表示指定线程池的拒绝策略，当线程池的任务已经在缓存队列workQueue中存储满了之后，并且不能创建新的线程来执行此任务时，就会用到此拒绝策略，它属于一种限流保护的机制。

 

 

答：核心是用ThreadPoolExecutor这个构造函数但是我们大多数使用封装类 Executors（jdk1.5并发包）提供四种线程池类型，分别为：
newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。

总结: 线程池为无限大，当执行第二个任务时第一个任务已经完成，会复用执行第一个任务的线程，而不用每次新建线程。
newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。

总结:因为线程池大小为3，每个任务输出index后sleep 2秒，所以每两秒打印3个数字。

定长线程池的大小最好根据系统资源进行设置。如Runtime.getRuntime().availableProcessors()
newScheduledThreadPool 创建一个定长线程池，支持定时及周期性任务执行。
newSingleThreadExecutor 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。

答：execute() 和 submit() 都是用来执行线程池任务的，它们最主要的区别是，submit() 方法可以接收线程池执行的返回值，而 execute() 不能接收返回值。

submit()方法可以配合Futrue来接收线程执行的返回值。它们的另一个区别是execute()方法属于Executor接口的方法，而 submit() 方法则是属于 ExecutorService 接口的方法

 

当线程池中的任务队列已经被存满，再有任务添加时会先判断当前线程池中的线程数是否大于等于线程池的最大值，如果是，则会触发线程池的拒绝策略。

Java自带的拒绝策略有4种：

1.AbortPolicy，终止策略，线程池会抛出异常并终止执行，它是默认的拒绝策略；2.CallerRunsPolicy，把任务交给当前线程来执行；

3.DiscardPolicy，忽略此任务（最新的任务）；

4.DiscardOldestPolicy，忽略最早的任务（最先加入队列的任务）。

自定义拒绝策略

自定义拒绝策略只需要新建一个 RejectedExecutionHandler 对象，然后重写它的 rejectedExecution() 方法即可我们可以在 rejectedExecution 中添加自己业务处理的代码。

ThreadPoolExecutor的扩展主要是通过重写它的beforeExecute()和afterExecute()方法实现的，我们可以在扩展方法中添加日志或者实现数据统计，比如统计线程的执行时间

  • 答：JDK Atomic开头的原子类、synchronized、LOCK，可以解决原子性问题
  • synchronized、volatile、LOCK，可以解决可见性问题
  • Happens-Before 规则可以解决有序性问题

答：

synchronized 锁升级原理：在锁对象的对象头里面有一个 threadid 字段，在第一次访问的时候 threadid 为空，jvm 让其持有偏向锁，并将 threadid 设置为其线程 id，再次进入的时候会先判断 threadid 是否与其线程 id 一致，如果一致则可以直接使用此对象，如果不一致，则升级偏向锁为轻量级锁，通过自旋循环一定次数来获取锁，执行一定次数之后，如果还没有正常获取到要使用的对象，此时就会把锁从轻量级升级为重量级锁，此过程就构成了 synchronized 锁的升级。

锁的升级的目的：锁升级是为了减低了锁带来的性能消耗。在 Java 6 之后优化 synchronized 的实现方式，使用了偏向锁升级为轻量级锁再升级到重量级锁的方式，从而减低了锁带来的性能消耗。

答：当线程 A 持有独占锁a，并尝试去获取独占锁 b 的同时，线程 B 持有独占锁 b，并尝试获取独占锁 a 的情况下，就会发生 AB 两个线程由于互相持有对方需要的锁，而发生的阻塞现象，我们称为死锁。

数据库死锁、线程死锁 行锁 表锁;

 

答：

  • 尽量使用 tryLock(long timeout, TimeUnit unit)的方法(ReentrantLock、ReentrantReadWriteLock)，设置超时时间，超时可以退出防止死锁。
  • 尽量使用 Java. util. concurrent 并发类代替自己手写锁。
  • 尽量降低锁的使用粒度，尽量不要几个功能用同一把锁。
  • 尽量减少同步的代码块。

答：ThreadLocal用于保存某个线程共享变量。使用场景：解决数据库连接，Session管理

解释：ThreadLocal 是线程本地存储，在每个线程中都创建了一个 ThreadLocalMap 对象，每个线程可以访问自己内部 ThreadLocalMap 对象内的 value。互不影响

经典的使用场景是为每个线程分配一个 JDBC 连接 Connection。这样就可以保证每个线程的都在各自的 Connection 上进行数据库的操作，不会出现 A 线程关了 B线程正在使用的 Connection； 还有 Session 管理 等问题。

 

ThreadLocal是通过下面的方式来实现为每一个线程维护变量的副本的：

在ThreadLocal类中定义了一个ThreadLocalMap，每一个Thread都有一个ThreadLocalMap类型的变量threadLocals，就是用threadLocals来存储每一个线程的变量副本，threadLocals内部有一个Entry数组，我们根据键值线程对象，来找到对应线程的变量副本。

 

1.对象锁钥匙只能有一把才能互斥，才能保证共享变量的唯一性

    2.在静态方法上的锁，和 实例方法上的锁，默认不是同样的，如果同步需要制定两把锁一样。

    3.关于同一个类的方法上的锁，来自于调用该方法的对象，如果调用该方法的对象是相同的，那么锁必然相同，否则就不相同。比如 new A().x() 和 new A().x(),对象不同，锁不同，如果A的单利的，就能互斥。

    4.静态方法加锁，能和所有其他静态方法加锁的 进行互斥

    5.静态方法加锁，和xx.class 锁效果一样，直接属于类的

 

答： synchronized 是由一对 monitorenter/monitorexit 指令实现的，monitor 对象是同步的基本实现单元。在 Java 6 之前，monitor 的实现完全是依靠操作系统内部的互斥锁，因为需要进行用户态到内核态的切换，所以同步操作是一个无差别的重量级操作，性能也很低。但在 Java 6 的时候，Java 虚拟机 对此进行了大刀阔斧地改进，提供了三种不同的 monitor 实现，也就是常说的三种不同的锁：偏向锁（Biased Locking）、轻量级锁和重量级锁，大大改进了其性能。

仅有ACC_SYNCHRONIZED这么一个标志，该标记表明线程进入该方法时，需要monitorenter，退出该方法时需要monitorexit。

synchronized 属于独占式锁 通过jvm隐式实现的 只允许同一个时刻只有一个线程操作资源

答：

仅靠volatile不能保证线程的安全性。（原子性）

①volatile轻量级，只能修饰变量。synchronized重量级，还可修饰方法

②volatile只能保证数据的可见性，不能用来同步，因为多个线程并发访问volatile修饰的变量不会阻塞。

synchronized不仅保证可见性，而且还保证原子性，因为，只有获得了锁的线程才能进入临界区，从而保证临界区中的所有语句都全部执行。多个线程争抢synchronized锁对象时，会出现阻塞。

线程安全性

线程安全性包括两个方面，①可见性。②原子性。

从上面自增的例子中可以看出：仅仅使用volatile并不能保证线程安全性。而synchronized则可实现线程的安全性。

 

Lock 接口可以尝试非阻塞地获取锁 当前线程尝试获取锁。如果这一时刻锁没有被其他线程获取到，则成功获取并持有锁。
*Lock 接口能被中断地获取锁 与 synchronized 不同，获取到锁的线程能够响应中断，当获取到的锁的线程被中断时，中断异常将会被抛出，同时锁会被释放。

Lock 接口在指定的截止时间之前获取锁，如果截止时间到了依旧无法获取锁，则返回。

答：

synchronized 早期的实现比较低效，对比 ReentrantLock，大多数场景性能都相差较大，但是在 Java 6 中对 synchronized 进行了非常多的改进。

主要区别如下：

  • synchronized是JVM隐式实现的，而ReentrantLock是Java语言提供的API；
  • ReentrantLock可设置为公平锁，而synchronized却不行；
  • ReentrantLock只能修饰代码块，而synchronized可以用于修饰方法、修饰代码块等；
  • ReentrantLock 需要手动加锁和释放锁，如果忘记释放锁，则会造成资源被永久占用，而 synchronized 无需手动释放锁；
  • ReentrantLock 可以知道是否成功获得了锁，而 synchronized  却不行。

ReentrantLock是基于AQS()实现的
默认是通过非公平锁实现的，他的内部有一个state的状态字段 用于表示锁是否被占用 如果是0则表示锁未被占用，此刻线程就可以把state改为1，并成功获得锁 ，而其他胃获取锁的线程只能去排队等待获取锁资源

 

公平锁的含义是线程需要按照请求的顺序来获得锁；而非公平锁则允许“插队”的情况存在，所谓的“插队”指的是，线程在发送请求的同时该锁的状态恰好变成了可用，那么此线程就可以跳过队列中所有排队的线程直接拥有该锁。而公平锁由于有挂起和恢复所以存在一定的开销，因此性能不如非公平锁，所以ReentrantLock和synchronized都是非公平锁的实现方式。

锁升级其实就是从偏向锁到轻量级锁再到重量级锁升级的过程，这是 JDK 1.6 提供的优化功能，也称之为锁膨胀。

答：atomic 主要利用 CAS (Compare And Swap) 和 volatile 和 native 方法来保证原子操作，从而避免 synchronized 的高开销，执行效率大为提升。

解释：1、直接操作内存，使用Unsafe 这个类

2、使用 getIntVolatile(var1,
var2) 获取线程间共享的变量

3、采用CAS的尝试机制（核心所在），代码如下：

 

  public
final int getAndAddInt(Object var1, long var2, int var4) {

       
int var5;

       
do {

           
var5 = this.getIntVolatile(var1, var2);

        }
while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

 

       
return var5;

    }

 

 

可以看到这个do …. while {!this.compareAndSwapInt(var1, var2, var5, var5 + var4)} 。不断地使用CAS进行重试，直到执行成功为止。这里是一个乐观锁的操作。

4、使用Atomic ，是在硬件上、寄存器尽心阻塞，而不是在线程、代码上阻塞。

5、这个是通俗说法ABA的问题

答:当多个线程同时共享，同一个全局变量或静态变量，做写的操作时，可能会发生数据冲突问题，也就是线程安全问题。做读操作是不会发生数据冲突问题。

答:使用多线程之间同步或使用锁(lock)。

答:将可能会发生数据冲突问题(线程不安全问题)，只能让当前一个线程进行执行。被包裹的代码执行完成后释放锁，让后才能让其他线程进行执行。这样的话就可以解决线程不安全问题。

答:当多个线程共享同一个资源,不会受到其他线程的干扰。

答:就是将可能会发生线程安全问题的代码，给包括起来。只能让当前一个线程进行执行，被包裹的代码执行完成之后才能释放所，让后才能让其他线程进行执行。

1.使用同步代码块？

synchronized(同一个数据){

 可能会发生线程冲突问题

}

     private Object mutex = new Object();// 自定义多线程同步锁

      public void sale()
{

            synchronized
(mutex) {

                  if
(trainCount > 0) {

try {

                             Thread.sleep(10);

                       }
catch (Exception e) {

                       }

                       System.out.println(Thread.currentThread().getName()
+ “,出售 第” + (100 – trainCount + 1) +
“张票.”);

                       trainCount–;               }

            }

      }

 

2.使用同步函数

在方法上修饰synchronized 称为同步函数

public synchronized void sale() {

                  if
(trainCount > 0) {

try {

                             Thread.sleep(40);

                       }
catch (Exception e) {

                       }

                       System.out.println(Thread.currentThread().getName()
+ “,出售 第” + (100 – trainCount + 1) +
“张票.”);

                       trainCount–;

                  }

      }

 

3.静态同步函数

方法上加上static关键字，使用synchronized 关键字修饰 为静态同步函数

静态的同步函数使用的锁是  该函数所属字节码文件对象

答:

同步代码使用自定锁(明锁)

同步函数(同步方法)使用this锁

注意:有些面试会这样问：例如现在一个静态方法和一个非静态静态怎么实现同步？

答:

同步函数使用this锁

静态同步函数使用字节码文件，也就是类.class

答：

同步中嵌套同步

解决办法:同步中尽量不要嵌套同步

1使用退出标识，使得线程正常退出，即当run方法完成后进程终止。

2使用stop强行中断线程（此方法为作废过期方法），不推荐使用

3、使用interrupt方法中断线程。(在Thread.java类里提供了两种方法判断线程是否为停止的。this.interrupted():测试当前线程是否已经中断（静态方法）。如果连续调用该方法，则第二次调用将返回false。在api文档中说明interrupted()方法具有清除状态的功能。执行后具有将状态标识清除为false的功能。this.isInterrupted():测试线程是否已经中断，但是不能清除状态标识。

 

线程分为两种 一种是守护线程（后台线程） 一种用户线程(前台线程)

  主线程或jvm进程挂了，守护线程也会被停止掉。gc其实也是守护线程。

多线程有三大特性，原子性、可见性、有序性

可见性：当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值

Java内存模型: java内存模型简称jmm，定义了一个线程对另一个线程可见。共享变量存放在主内存中，每个线程都有自己的本地内存，当多个线程同时访问一个数据的时候，可能本地内存没有及时刷新到主内存，所以就会发生线程安全问题

自旋锁

自旋锁是采用让当前线程不停地的在循环体内执行实现的，当循环的条件被其他线程改变时 才能进入临界区

互斥锁

所谓互斥锁, 指的是一次最多只能有一个线程持有的锁. 在jdk1.5之前, 我们通常使用synchronized机制控制多个线程对共享资源Lock接口及其实现类ReentrantLock

可重入锁

可重入锁，也叫做递归锁，指的是同一线程 外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码，但不受影响。
在JAVA环境下 ReentrantLock 和synchronized 都是 可重入锁

悲观锁

悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系
统不会修改数据）。

乐观锁

相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库
性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。 而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如
果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

 

名称

作用

Lock

锁

Executors

线程池

ReentrantLock

一个可重入的互斥锁定 Lock，功能类似synchronized，但要强大的多。

Condition

 Condition的功能类似于在传统的线程技术中的,Object.wait()和Object.notify()的功能,

 

ConcurrentHashMap

分段HasMap

AtomicInteger

原子类

BlockingQueue

 

BlockingQueue 通常用于一个线程生产对象，而另外一个线程消费这些对象的场景

ExecutorService

 

执行器服务

 线程池是指在初始化一个多线程应用程序过程中创建一个线程集合，然后在需要执行新的任务时重用这些线程而不是新建一个线程。线程池中线程的数量通常完全取决于可用内存数量和应用程序的需求。然而，增加可用线程数量是可能的。线程池中的每个线程都有被分配一个任务，一旦任务已经完成了，线程回到池子中并等待下一次分配任务。

 

基于以下几个原因在多线程应用程序中使用线程是必须的：

  1. 线程池改进了一个应用程序的响应时间。由于线程池中的线程已经准备好且等待被分配任务，应用程序可以直接拿来使用而不用新建一个线程。

  2. 线程池节省了CLR 为每个短生存周期任务创建一个完整的线程的开销并可以在任务完成后回收资源。

  3. 线程池根据当前在系统中运行的进程来优化线程时间片。

  4. 线程池允许我们开启多个任务而不用为每个线程设置属性。

  5. 线程池允许我们为正在执行的任务的程序参数传递一个包含状态信息的对象引用。

  6. 线程池可以用来解决处理一个特定请求最大线程数量限制问题。

 

Java通过Executors（jdk1.5并发包）提供四种线程池，分别为：
newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。
newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。
newScheduledThreadPool 创建一个定长线程池，支持定时及周期性任务执行。
newSingleThreadExecutor 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。

 

就是正在运行，动态获取这个类的所有信息。

Xml是重量级数据交换格式，占宽带比较大。

JSON是轻量级交换格式，xml占宽带小。

所有很多互联网公司都会使用json作为数据交换格式

很多银行项目，大多数还是在使用xml。

  1，反编译：.class–>.java

   2．通过反射机制访问java对象的属性，方法，构造方法等；

反射机制的应用场景

Jdbc 加载驱动—–

Spring ioc

框架  

答：系列化就是把java对象转换为字节序列的方法。

  • 把对象的字节序列化到永久的保存到硬盘中
  • 在网络上传递对象的字节序列

答：动态代理是运行时动态生成代理类。

  • 动态代理指的是可以任意控制任意对象的执行过程
    • 本来应该自己做的事情，因为没有某种原因不能直接做，只能请别人代理做。被请的人就是代理
    • 比如春节买票回家，由于没有时间，只能找票务中介来买，这就是代理模式
  • 应用：Spring 的 AOP

 

答：

  • JDK动态代理  应用场景  一定要实现接口
  • cglib动态代理   spring源码用到  注册一个bean用到   他们不用实现同一个接口

 

答：克隆的对象可能包含一些已经修改过的属性，而 new 出来的对象的属性都还是初始化时候的值，所以当需要一个新的对象来保存当前对象的“状态”就靠克隆方法了。

答：

  • 实现 Cloneable 接口并重写 Object 类中的 clone() 方法。
  • 实现 Serializable 接口，通过对象的序列化和反序列化实现克隆，可以实现真正的深度克隆。

答：

  • 浅克隆：当对象被复制时只复制它本身和其中包含的值类型的成员变量，而引用类型的成员对象并没有复制。
  • 深克隆：除了对象本身被复制外，对象所包含的所有成员变量也将复制。

答：

  • jsp经编译后就成了Servlet（Jsp的本质就是Servlet，JVM只能识别Java类，不能识别Jsp代码，Web容器将Jsp的代码编译成JVM能够识别的java类）
  • jsp更擅长表现于页面显示，servlet更擅长于逻辑控制
  • Servlet中没有内置对象，Jsp中的内置对象都是必须通过HttpServletRequest对象，HttpServletResponse对象以及HttpServlet对象得到

65.jsp 有哪些内置对象？作用分别是什么？

request 用户端请求，此请求会包含来自GET/POST请求的参数

response 网页传回用户端的回应

pageContext 网页的属性是在这里管理

session 与请求有关的会话期

application servlet 正在执行的内容

out 用来传送回应的输出

config servlet的构架部件

page JSP网页本身

exception 针对错误网页，未捕捉的例外

 

答：

  • 存储位置不同：session 存储在服务器端；cookie 存储在浏览器端。
  • 安全性不同：cookie 安全性一般，在浏览器存储，可以被伪造和修改。
  • 容量和个数限制：cookie 有容量限制，每个站点下的 cookie 也有个数限制。
  • 存储的多样性：session 可以存储在 Redis 中、数据库中、应用程序中；而 cookie 只能存储在浏览器中

第一http协议是无状态的 当我们在开发一些对状态有要求的接口 cookie和session弥补这一块的能力

第二 对于http协议 cookie只是请求头当中的一个字段，他跟http协议请求头当中的其他字段并没有太大的区别，特别当我们把他放在四层tcp角度来看 那么http的请求头和请求体更没有什么大的区别

第三 浏览器对cookie做了默认的支持 同时也限制的cookie 比如同源策略   同源策略是浏览器基于安全角度的一个机制 限制的同域才能访问cookie的内容，对于同域的定义就是相同的协议 域名 端口 这个时候当我们做单点登录sso功能的时候 就会考虑把cookie种在可以、访问的域下面 比如把cookie种在一级域名下面

 

session 是服务器为每一个web用户分配的独立状态存储空间

答：session 的工作原理是客户端登录完成之后，服务器会创建对应的 session，session 创建完之后，会把 session 的 id 发送给客户端，客户端再存储到浏览器中。这样客户端每次访问服务器时，都会带着 sessionid，服务器拿到 sessionid 之后，在内存找到与之对应的 session 这样就可以正常工作了

答：可以用，session 只是依赖 cookie 存储 sessionid，如果 cookie 被禁用了，可以使用 url 中添加 sessionid 的方式保证 session 能正常使用

答：

  • 拦截级别：struts2 是类级别的拦截；spring mvc 是方法级别的拦截。
  • 数据独立性：spring mvc 的方法之间基本上独立的，独享 request 和 response 数据，请求数据通过参数获取，处理结果通过 ModelMap 交回给框架，方法之间不共享变量；而 struts2 虽然方法之间也是独立的，但其所有 action 变量是共享的，这不会影响程序运行，却给我们编码和读程序时带来了一定的麻烦。
  • 拦截机制：struts2 有以自己的 interceptor 机制，spring mvc 用的是独立的 aop 方式，这样导致struts2 的配置文件量比 spring mvc 大。
  • 对 ajax 的支持：spring mvc 集成了ajax，所有 ajax 使用很方便，只需要一个注解 @ResponseBody 就可以实现了；而 struts2 一般需要安装插件或者自己写代码才行。

 

1）过滤器需要在web.xml中配置，依赖于Servlet；

（2）拦截器需要在SpringMVC中配置，依赖于框架；

（3）过滤器的执行顺序在拦截器之前，具体的流程见下图；

（4）两者的本质区别：拦截器是基于Java的反射机制，而过滤器（Filter）是基于函数回调。从灵活性上说拦截器功能更强大些，过滤器能做的事情，都能做，而且可以在请求前，请求后执行，比较灵活。过滤器主要是针对URL地址做一个编码的事情、过滤掉没用的参数、安全校验（比较泛的，比如登录不登录之类），太细的话，还是建议用拦截器。不过还是根据不同情况选择合适的。

 

答：

  • 使用预处理 PreparedStatement。
  • 使用正则表达式过滤掉字符中的特殊字符。

答：

XSS 攻击：即跨站脚本攻击，它是 Web 程序中常见的漏洞。原理是攻击者往 Web 页面里插入恶意的脚本代码（css 代码、Javascript 代码等），当用户浏览该页面时，嵌入其中的脚本代码会被执行，从而达到恶意攻击用户的目的，如盗取用户 cookie、破坏页面结构、重定向到其他网站等。

预防 XSS 的核心是使用Fileter过滤器注入标签

 

答：CSRF：Cross-Site Request Forgery（中文：跨站请求伪造），可以理解为攻击者盗用了你的身份，以你的名义发送恶意请求，比如：以你名义发送邮件、发消息、购买商品，虚拟货币转账等。

防御手段：

  • 验证请求来源地址；
  • 关键操作添加验证码；
  • 在请求地址添加 token 并验证

 

答：

  • throw则是指抛出的一个具体异常类型
  • throws是用来声明一个方法可能抛出的所有异常信息

解释：1.用户程序自定义的异常和应用程序特定的异常,必须借助于 throws 和
throw 语句来定义抛出异常。

1.1   throw是语句抛出一个异常。
语法：throw (异常对象);
        
throw e;

1.2   throws是方法可能抛出异常的声明。(用在声明方法时，表示该方法可能要抛出异常)
语法：[(修饰符)](返回值类型)(方法名)([参数列表])[throws(异常类)]{……}
           
public void doA(int a) throws Exception1,Exception3{……}

答：

  • final 是用来修饰类、方法、变量
  • finally 只能用在 try catch 语法中，表示这段语句最终一定会被执行

解释：一、final ：

  • 1、修饰符（关键字） 如果一个类被声明为final,意味着它不能再派生新的子类，不能作为父类被继承。因此一个类不能及被声明为abstract，又被声明为final的。
  • 2、将变量或方法声明为final,可以保证他们使用中不被改变。被声明为final的变量必须在声明时给定初值，而以后的引用中只能读取，不可修改，被声明为final的方法也同样只能使用，不能重载。
  • 二、finally:
  • 在异常处理时提供finally块来执行清楚操作。如果抛出一个异常，那么相匹配的catch语句就会执行，然后控制就会进入finally块，如果有的话。
  • 三、finalize：
  • 是方法名。java技术允许使用finalize()方法在垃圾收集器将对象从内存中清除之前做必要的清理工作。这个方法是在垃圾收集器在确定了，被清理对象没有被引用的情况下调用的。
  • finalize是在Object类中定义的，因此，所有的类都继承了它。子类可以覆盖finalize()方法，来整理系统资源或者执行其他清理工作。

 

答：try-catch-finally
其中 catch 和 finally 都可以被省略，但是不能同时省略，也就是说有 try 的时候，必须后面跟一个 catch 或者 finally

答：一定会， catch 中 return会等finally中的代码执行完之后才会执行

  • NullPointerException 空指针异常
  • ClassNotFoundException 指定类不存在
  • NumberFormatException 字符串转换为数字异常
  • IndexOutOfBoundsException 数组下标越界异常
  • ClassCastException 数据类型转换异常
  • FileNotFoundException 文件未找到异常
  • NoSuchMethodException 方法不存在异常
  • IOException IO 异常
  • SocketException Socket 异常

应用层、传输层、网络层、链路层

Socket就是为网络服务提供的一种机制。

通讯的两端都有Sokcet

网络通讯其实就是Sokcet间的通讯

数据在两个Sokcet间通过IO传输。

 

udp: a、是面向无连接, 将数据及源的封装成数据包中,不需要建立建立连接

    b、每个数据报的大小在限制64k内

    c、因无连接,是不可靠协议

    d、不需要建立连接,速度快

tcp： a、建议连接，形成传输数据的通道.

    b、在连接中进行大数据量传输，以字节流方式

    c 通过三次握手完成连接,是可靠协议

d 必须建立连接m效率会稍低

 

答：

  • 301表示网页永久性转移到另一个地址
  • 302表示临时性转移
  • 区别：
    • 301是永久的重定向，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址
    • 302重定向是临时的重定向，搜索引擎抓取新的内容而保留旧的网址

答： 是servlet的主要两种跳转方式，forward又叫1）转发

                             a）地址栏不会改变

                             b）转发只能转发到当前web应用内的资源

                            c）可以在转发过程中，可以把数据保存到request域对象中

 

                     2）重定向                  

                            a）地址栏会改变，变成重定向到地址。

                            b）重定向可以跳转到当前web应用，或其他web应用，甚至是外部域名网站。

                            c）不能再重定向的过程，把数据保存到request中。

                自定义重定向:

                 

response.setStatus(302); 

response.setHeader(“Location”,”OtherServlet”); 

 

 

第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize
Sequence Numbers）。

 

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；

 

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

 

 

【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？

 

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

 

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

 

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum
Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

 

【问题3】为什么不能用两次握手进行连接？

 

答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

 

       现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

 

【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？

 

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

　1、https 协议需要到 ca 申请证书，一般免费证书较少，因而需要一定费用。

　2、http 是超文本传输协议，信息是明文传输，https 则是具有安全性的 ssl 加密传输协议。

　3、http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。

　4、http 的连接很简单，是无状态的；HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 http 协议安全。

我们都知道 HTTPS 能够加密信息，以免敏感信息被第三方获取，所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用 HTTPS 协议。

　客户端在使用 HTTPS 方式与 Web 服务器通信时有以下几个步骤，如图所示。

　　（1）客户使用 https 的 URL 访问 Web 服务器，要求与 Web 服务器建立 SSL 连接。

　　（2）Web 服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

　　（3）客户端的浏览器与 Web 服务器开始协商 SSL 连接的安全等级，也就是信息加密的等级。

　　（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

　　（5）Web 服务器利用自己的私钥解密出会话密钥。

　　（6）Web 服务器利用会话密钥加密与客户端之间的通信。

https优缺点？

　虽然说 HTTPS 有很大的优势，但其相对来说，还是存在不足之处的：

　　（1）HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近 50%，增加 10% 到 20% 的耗电；

　　（2）HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

　　（3）SSL 证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

　 （4）SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗。

　　（5）HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

 

答：

　　如果采用两次握手，那么只要服务器发出确认数据包就会建立连接，但由于客户端此时并未响应服务器端的请求，那此时服务器端就会一直在等待客户端，这样服务器端就白白浪费了一定的资源。若采用三次握手，服务器端没有收到来自客户端的再此确认，则就会知道客户端并没有要求建立请求，就不会浪费服务器的资源

答：

tcp 粘包可能发生在发送端或者接收端，分别来看两端各种产生粘包的原因：

  • 发送端粘包：发送端需要等缓冲区满才发送出去，造成粘包；
  • 接收方粘包：接收方不及时接收缓冲区的包，造成多个包接收。

答：

  • 物理层：利用传输介质为数据链路层提供物理连接，实现比特流的透明传输。(光纤)
  • 数据链路层：负责建立和管理节点间的链路。
  • 网络层：通过路由选择算法，为报文或分组通过通信子网选择最适当的路径。
  • 传输层：向用户提供可靠的端到端的差错和流量控制，保证报文的正确传输。
  • 会话层：向两个实体的表示层提供建立和使用连接的方法。
  • 表示层：处理用户信息的表示问题，如编码、数据格式转换和加密解密等。
  • 应用层：直接向用户提供服务，完成用户希望在网络上完成的各种工作。

答：

  • get请求的参数在URL中，而post 请求在请求body中
  • get请求传参有长度限制，post请求没有长度限制
  • get请求的参数只能是ASCII码，post请求传参没有这个限制

解释：在浏览器进行回退操作时,get请求是无害的,而post请求则会重新请求一次

get请求参数是连接在url后面的,而post请求参数是存放在requestbody内的

get请求因为浏览器对url长度有限制(不同浏览器长度限制不一样)对传参数量有限制,而post请求因为参数存放在requestbody内所以参数数量没有限制(事实上get请求也能在requestbody内携带参数,只不过不符合规定,有的浏览器能够获取到数据,而有的不能)

因为get请求参数暴露在url上,所以安全方面post比get更加安全

get请求浏览器会主动cache,post并不会,除非主动设置

get请求参数会保存在浏览器历史记录内,post请求并不会

get请求只能进行url编码,而post请求可以支持多种编码方式

get请求产生1个tcp数据包,post请求产生2个tcp数据包

浏览器在发送get请求时会将header和data一起发送给服务器,服务器返回200状态码,而在发送post请求时,会先将header发送给服务器,服务器返回100,之后再将data发送给服务器,服务器返回200 OK

答：

  • 使用JSONP
  • 在响应头中设置允许跨域
  • 使用接口网关 nginx转发
  • 使用后台服务转发

解释：1.最经典的跨域方案jsonp
jsonp本质上是一个Hack，它利用<script>标签不受同源策略限制的特性进行跨域操作。
jsonp优点：
实现简单
兼容性非常好

jsonp的缺点：
只支持get请求（因为<script>标签只能get）
有安全性问题，容易遭受xss攻击
需要服务端配合jsonp进行一定程度的改造

 

        <script
type=”text/javascript”>

            function
JSONP({ 

              url,

              params,

              callbackKey,

              callback

            }) {

              // 在参数里制定 callback 的名字

              params = params || {}

              params[callbackKey] = \’jsonpCallback\’

                // 预留
callback

              window.jsonpCallback = callback

                // 拼接参数字符串

              const paramKeys =
Object.keys(params)

              const paramString = paramKeys

                .map(key => `${key}=${params[key]}`)

                .join(\’&\’)

                // 插入
DOM 元素

              const script =
document.createElement(\’script\’)

              script.setAttribute(\’src\’,
`${url}?${paramString}`)

              document.body.appendChild(script)

            }

           

            JSONP({ 

              url:
\’http://s.weibo.com/ajax/jsonp/suggestion\’,

              params: {

                key: \’test\’,

              },

              callbackKey: \’_cb\’,

              callback(result) {

                console.log(result.data)

              }

            })

        </script>

 

2.最流行的跨域方案cors
cors是目前主流的跨域解决方案，跨域资源共享(CORS) 是一种机制，它使用额外的 HTTP 头来告诉浏览器
让运行在一个 origin (domain) 上的Web应用被准许访问来自不同源服务器上的指定的资源。
当一个资源从与该资源本身所在的服务器不同的域、协议或端口请求一个资源时，资源会发起一个跨域 HTTP 请求。
如果你用express，可以这样在后端设置

 

        <script
type=”text/javascript”>

            //CORS middleware

            var
allowCrossDomain = function(req, res, next) {

                res.header(\’Access-Control-Allow-Origin\’,
\’http://example.com\’);

               
res.header(\’Access-Control-Allow-Methods\’, \’GET,PUT,POST,DELETE\’);

               
res.header(\’Access-Control-Allow-Headers\’, \’Content-Type\’);

           

                next();

            }

           

            //…

            app.configure(function() {

                app.use(express.bodyParser());

               
app.use(express.cookieParser());

                app.use(express.session({
secret: \’cool beans\’ }));

                app.use(express.methodOverride());

                app.use(allowCrossDomain);

                app.use(app.router);

               
app.use(express.static(__dirname + \’/public\’));

            });

        </script>

 

3.最方便的跨域方案Nginx
nginx是一款极其强大的web服务器，其优点就是轻量级、启动快、高并发。
现在的新项目中nginx几乎是首选，我们用node或者java开发的服务通常都需要经过nginx的反向代理。
反向代理的原理很简单，即所有客户端的请求都必须先经过nginx的处理，nginx作为代理服务器再讲请求转发给node或者java服务，这样就规避了同源策略。

 

        <script
type=”text/javascript”>

            #进程, 可更具cpu数量调整

            worker_processes  1;

           

            events {

                #连接数

                worker_connections  1024;

            }

           

            http {

                include       mime.types;

                default_type  application/octet-stream;

           

                sendfile        on;

           

                #连接超时时间，服务器会在这个时间过后关闭连接。

                keepalive_timeout  10;

           

                # gizp压缩

                gzip  on;

           

                # 直接请求nginx也是会报跨域错误的这里设置允许跨域

                # 如果代理地址已经允许跨域则不需要这些, 否则报错(虽然这样nginx跨域就没意义了)

                add_header
Access-Control-Allow-Origin *;

                add_header
Access-Control-Allow-Headers X-Requested-With;

                add_header Access-Control-Allow-Methods
GET,POST,OPTIONS;

           

                # srever模块配置是http模块中的一个子模块，用来定义一个虚拟访问主机

                server {

                    listen       80;

                    server_name  localhost;

                   

                    # 根路径指到index.html

                    location / {

                        root   html;

                        index  index.html index.htm;

                    }

           

                    # localhost/api 的请求会被转发到192.168.0.103:8080

                    location /api {

                        rewrite ^/b/(.*)$ /$1
break; # 去除本地接口/api前缀, 否则会出现404

                        proxy_set_header Host
$host;

                        proxy_set_header
X-Real-IP $remote_addr;

                        proxy_set_header
X-Forwarded-For $proxy_add_x_forwarded_for;

                        proxy_pass http://192.168.0.103:8080; # 转发地址

                    }

                   

                    # 重定向错误页面到/50x.html

                    error_page   500 502 503 504  /50x.html;

                    location = /50x.html {

                        root   html;

                    }

           

                }

           

            }

        </script>

 

4.其它跨域方案
HTML5 XMLHttpRequest 有一个API，postMessage()方法允许来自不同源的脚本采用异步方式进行有限的通信，可以实现跨文本档、多窗口、跨域消息传递。
WebSocket 是一种双向通信协议，在建立连接之后，WebSocket 的 server 与 client 都能主动向对方发送或接收数据，连接建立好了之后 client 与 server 之间的双向通信就与 HTTP 无关了，因此可以跨域。
window.name + iframe：window.name属性值在不同的页面（甚至不同域名）加载后依旧存在，并且可以支持非常长的 name 值，我们可以利用这个特点进行跨域。
location.hash + iframe：a.html欲与c.html跨域相互通信，通过中间页b.html来实现。 三个页面，不同域之间利用iframe的location.hash传值，相同域之间直接js访问来通信。
document.domain + iframe： 该方式只能用于二级域名相同的情况下，比如 a.test.com 和 b.test.com 适用于该方式，我们只需要给页面添加 document.domain
=\’test.com\’ 表示二级域名都相同就可以实现跨域，两个页面都通过js强制设置document.domain为基础主域，就实现了同域。

6.其余方案来源于九种跨域方式

 

答：jsonp是一种轻量级的数据交换格式。

  • ajax 请求受同源策略影响，不允许进行跨域请求，而 script 标签 src 属性中的链接却可以访问跨域的js脚本，利用这个特性，服务端不再返回JSON格式的数据，而是返回一段调用某个函数的js代码，在src中进行了调用，这样实现了跨域。

 

1、在浏览器中输入www.qq.com域名，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。 
2、如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。

答：

  • 单例模式：保证被创建一次，节省系统开销。
  • 工厂模式（简单工厂、抽象工厂）：解耦代码。
  • 观察者模式：定义了对象之间的一对多的依赖，这样一来，当一个对象改变时，它的所有的依赖者都会收到通知并自动更新。

答：是由一个工厂对象创建产品实例，简单工厂模式的工厂类一般是使用静态方法，通过不同的参数的创建不同的对象实例可以生产结构中的任意产品，不能增加新的产品

抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无需制定他们具体的类，生产多个系列产品生产不同产品族的全部产品，不能新增产品，可以新增产品族

设计模式（Design
pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

 

总体来说设计模式分为三大类：

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

1、开闭原则（Open Close Principle）

开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

2、里氏代换原则（Liskov Substitution Principle）

里氏代换原则(Liskov
Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。——
From Baidu 百科

3、依赖倒转原则（Dependence Inversion Principle）

这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。

4、接口隔离原则（Interface Segregation Principle）

这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。

5、迪米特法则（最少知道原则）（Demeter Principle）

为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。

6、合成复用原则（Composite Reuse Principle）

原则是尽量使用合成/聚合的方式，而不是使用继承。

 单例保证一个对象JVM中只能有一个实例,常见单例 懒汉式、饿汉式

 什么是懒汉式,就是需要的才会去实例化,线程不安全。

 什么是饿汉式,就是当class文件被加载的时候，初始化，天生线程安全。

实现创建者和调用者分离

通过代理控制对象的访问,可以详细访问某个对象的方法，在这个方法调用处理，或调用后处理。既(AOP微实现) 
,AOP核心技术面向切面编程。

 

安全代理 可以屏蔽真实角色

远程代理 远程调用代理类RMI

延迟加载 先加载轻量级代理类,真正需要在加载真实

静态代理(静态定义代理类)

动态代理(动态生成代理类)

Jdk自带动态代理

Cglib 、javaassist（字节码操作库）

实现InvocationHandler 就可以了

CGLIB动态代理

jdk动态代理是由Java内部的反射机制来实现的，cglib动态代理底层则是借助asm来实现的。总的来说，反射机制在生成类的过程中比较高效，而asm在生成类之后的相关执行过程中比较高效（可以通过将asm生成的类进行缓存，这样解决asm生成类过程低效问题）。还有一点必须注意：jdk动态代理的应用前提，必须是目标类基于统一的接口。如果没有上述前提，jdk动态代理不能应用。

注:asm其实就是java字节码控制.

fastjson(阿里)、gson(谷歌)、jackson(SpringMVC自带)

Dom4j、Sax、Pull

 dom4j不适合大文件的解析，因为它是一下子将文件加载到内存中，所以有可能出现内存溢出，sax是基于事件来对xml进行解析的，所以他可以解析大文件的xml，也正是因为如此，所以dom4j可以对xml进行灵活的增删改查和导航，而sax没有这么强的灵活性，所以sax经常是用来解析大型xml文件，而要对xml文件进行一些灵活（crud）操作就用dom4j。

 

Xml是重量级数据交换格式，占宽带比较大。

JSON是轻量级交换格式，xml占宽带小。

所有很多互联网公司都会使用json作为数据交换格式

很多银行项目，大多数还是在使用xml。

 

 

Jdk1.5新增新技术，注解。很多框架为了简化代码，都会提供有些注解。可以理解为插件，是代码级别的插件，在类的方法上写：@XXX，就是在代码上插入了一个插件。

注解不会也不能影响代码的实际逻辑，仅仅起到辅助性的作用。

注解分类：内置注解(也成为元注解 jdk 自带注解)、自定义注解（Spring框架中用到的注解）

  1. 内置注解：Deprecated、

答：spring是一个开源框架，是个轻量级的控制反转(IoC)和面向切面(AOP)的容器框架

  • 方便结构简化开发
  • AOP编码的支持
  • 声明式事物的支持
  • 方便程序的测试
  • 方便集成各种优势框架
  • 降低Java EE API 的使用难度

 答：AOP即面向切面编程，是OOP编程的有效补充。使用AOP技术，可以将一些系统性相关的编程工作，独立提取出来，独立实现，然后通过切面切入进系统。从而避免了在业务逻辑的代码中混入很多的系统相关的逻辑——比如权限管理，事物管理，日志记录等等。

AOP分为静态AOP和动态AOP：

  • 静态AOP是指AspectJ实现的AOP，他是将切面代码直接编译到Java类文件中。
  • 动态AOP是指将切面代码进行动态织入实现的AOP，JDK动态代理。

答：即“控制反转”，不是什么技术，而是一种设计思想。在Java开发中，Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。

IoC很好的体现了面向对象设计法则之一—— 好莱坞法则：“别找我们，我们找你”；即由IoC容器帮对象找相应的依赖对象并注入，而不是由对象主动去找。

 

1.读取bean的XML配置文件

2.使用beanId查找bean配置，并获取配置文件中class地址。

3.使用Java反射技术实例化对象

4.获取属性配置，使用反射技术进行赋值。

详细步骤

 

1.利用传入的参数获取xml文件的流,并且利用dom4j解析成Document对象

2.对于Document对象获取根元素对象<beans>后对下面的<bean>标签进行遍历,判断是否有符合的id.

3.如果找到对应的id,相当于找到了一个Element元素,开始创建对象,先获取class属性,根据属性值利用反射建立对象.

4.遍历<bean>标签下的property标签,并对属性赋值.注意,需要单独处理int,float类型的属性.因为在xml配置中这些属性都是以字符串的形式来配置的,因此需要额外处理.

5.如果属性property标签有ref属性,说明某个属性的值是一个对象,那么根据id(ref属性的值)去获取ref对应的对象,再给属性赋值.

6.返回建立的对象,如果没有对应的id,或者<beans>下没有子标签都会返回null

 

答：core模块、aop模块、data access模块、web模块、test模块

  • spring core：框架的最基础部分，提供 ioc 和依赖注入特性。
  • spring context：构建于 core 封装包基础上的 context 封装包，提供了一种框架式的对象访问方法。
  • spring dao：Data Access Object 提供了JDBC的抽象层。
  • spring aop：提供了面向切面的编程实现，让你可以自定义拦截器、切点等。
  • spring Web：提供了针对 Web 开发的集成特性，例如文件上传，利用 servlet listeners 进行 ioc 容器初始化和针对 Web 的 ApplicationContext。
  • spring Web mvc：spring 中的 mvc 封装包提供了 Web 应用的 Model-View-Controller（MVC）的实现。

答：

  • xml注解方式
  • Java注解的方式  @Compoanent或者@Bean
  • javaAPI注册方式   ImportBeanDefinitionRegistrar 

答：

spring 中的 bean 默认是单例模式，spring 框架并没有对单例 bean 进行多线程的封装处理。

实际上大部分时候 spring bean 无状态的（比如 dao 类），所有某种程度上来说 bean 也是安全的，但如果 bean 有状态的话（比如 view model 对象），那就要开发者自己去保证线程安全了，最简单的就是改变 bean 的作用域，把“singleton”变更为“prototype”，这样请求 bean 相当于 new Bean()了，所以就可以保证线程安全了。

  • 有状态就是有数据存储功能。
  • 无状态就是不会保存数据。

答：singleton、prototype、request、session、globalSession五中作用域。

  • singleton：spring ioc 容器中只存在一个 bean 实例，bean 以单例模式存在，是系统默认值；
  • prototype：每次从容器调用 bean 时都会创建一个新的示例，既每次 getBean()相当于执行 new Bean()操作；
  • Web 环境下的作用域：
    • request：每次 http 请求都会创建一个 bean；
    • session：同一个 http session 共享一个 bean 实例；
    • global-session：用于 portlet 容器，因为每个 portlet 有单独的 session，globalsession 提供一个全局性的 http session

答：可分为四种：

  • byName：按照bean的属性名称来匹配要装配的bean
  • byType：按照bean的类型来匹配要装配的bean
  • constructor：按照bean的构造器入参的类型来进行匹配 
  • autodetect（自动检测）：先使用constructor进行装配，如果不成功就使用byType来装配

答：

  • 声明式事务：声明式事务也有两种实现方式，基于 xml 配置文件的方式和注解方式（在类上添加 @Transaction 注解）。
  • 编码方式：提供编码的形式管理和维护事务。

答：

spring 有五大隔离级别，默认值为 ISOLATION_DEFAULT（使用数据库的设置），其他四个隔离级别和数据库的隔离级别一致：

  • ISOLATION_DEFAULT(isolation_default)：用底层数据库的设置隔离级别，数据库设置的是什么我就用什么；
  • ISOLATIONREADUNCOMMITTED(isolationreaduncommitted)：未提交读，最低隔离级别、事务未提交前，就可被其他事务读取（会出现幻读、脏读、不可重复读）；
  • ISOLATIONREADCOMMITTED：提交读，一个事务提交后才能被其他事务读取到（会造成幻读、不可重复读），SQL server 的默认级别；
  • ISOLATIONREPEATABLEREAD：可重复读，保证多次读取同一个数据时，其值都和事务开始时候的内容是一致，禁止读取到别的事务未提交的数据（会造成幻读），MySQL 的默认级别；
  • ISOLATION_SERIALIZABLE：序列化，代价最高最可靠的隔离级别，该隔离级别能防止脏读、不可重复读、幻读。
  • 脏读 ：表示一个事务能够读取另一个事务中还未提交的数据。比如，某个事务尝试插入记录 A，此时该事务还未提交，然后另一个事务尝试读取到了记录 A。
  • 不可重复读 ：是指在一个事务内，多次读同一数据。
  • 幻读 ：指同一个事务内多次查询返回的结果集不一样。比如同一个事务 A 第一次查询时候有 n 条记录，但是第二次同等条件下查询却有 n+1 条记录，这就好像产生了幻觉。发生幻读的原因也是另外一个事务新增或者删除或者修改了第一个事务结果集里面的数据，同一个记录的数据内容被修改了，所有数据行的记录就变多或者变少了

答：

  • spring mvc 先将请求发送给 DispatcherServlet。
  • DispatcherServlet 查询一个或多个 HandlerMapping，找到处理请求的 Controller。
  • DispatcherServlet 再把请求提交到对应的 Controller。
  • Controller 进行业务逻辑处理后，会返回一个ModelAndView。
  • Dispathcher 查询一个或多个 ViewResolver 视图解析器，找到 ModelAndView 对象指定的视图对象。
  • 视图对象负责渲染返回给客户端

答：

  • 前置控制器 DispatcherServlet
  • 映射控制器 HandlerMapping
  • 处理器 Controller
  • 模型和视图 ModelAndView
  • 视图解析器 ViewResolver

答：将 http 请求映射到相应的类/方法上

解释：@RequestMapping是一个用来处理请求地址映射的注解，可用于类或者方法上。用于类上，表示类中的所有响应请求的方法都是以该地址作为父路径。

@RequestMapping注解有六个属性，下面进行详细的说明。

1.value, method

value:指定请求的实际地址，指定的地址可以是URI Template模式。

method:指定请求的method类型，GET、POST、PUT、DELETE等。

2.consumes, produces

consumes:指定处理请求的提交内容类型（Content-Type），例如application/json,text/html。

produces:指定返回的内容类型，仅当request请求头中的（Accept）类型中包含该指定类型才返回。

3.params, headers

params:指定request中必须包含某些参数值才让该方法处理。

headers:指定request中必须包含某些指定的header值，才能让该方法处理请求。

答：@Autowired 它可以对类成员变量、方法及构造函数进行标注，完成自动装配的工作，通过@Autowired 的使用来消除 set/get 方法

@Autowired 是一个注释，它可以对类成员变量、方法及构造函数进行标注，让 spring 完成 bean 自动装配的工作。
@Autowired 默认是按照类去匹配，配合
@Qualifier 指定按照名称去装配 bean。

答：Spring Boot是一个构建在Spring框架顶部的项目。它提供了一种更简单、更快捷的方法来设置、配置和运行简单和基于Web的应用程序。

springboot就是Spring开源框架下的子项目，是Spring的一站式解决方案，主要是简化了spring的使用难度，降低了对配置文件的要求，使得开发人员能够更容易得上手。

答：

  • 配置简单
  • 独立运行
  • 自动装配
  • 无代码生成和 xml 配置
  • 提供应用监控
  • 易上手
  • 提升开发效率

spring boot 核心的两个配置文件：

  • bootstrap (. yml 或者 . properties)：boostrap 由父 ApplicationContext 加载的，比 applicaton 优先加载，且 boostrap 里面的属性不能被覆盖
  • application (. yml 或者 . properties)：用于 spring boot 项目的自动化配置

配置文件有 . properties 格式和 . yml 格式，它们主要的区别是书法风格不同。

. properties 配置如下：

spring. RabbitMQ.
port=5672

. yml 配置如下：

spring:

    RabbitMQ:

        port: 5672

. yml 格式不支持 @PropertySource 注解导入

1.使用springloaded配置pom.xml文件，使用mvn spring-boot:run启动

2.使用springloaded本地加载启动，配置jvm参数

-javaagent:<jar包地址> -noverify

3.使用devtools工具包，操作简单，但是每次需要重新部署

 

jpa 全称 Java Persistence API，是 Java 持久化接口规范，hibernate 属于 jpa 的具体实现。

   spring cloud就是一个rpc远程调用微服务框架、提供注册服务、发现服务、断路器、网关、自动配置、Eureka (注册中心)、ribbon(负载均衡)、rest、Feign(http协议调用工具)、Hystrix(断路器)、Zuul(网关)。底层通过httpclint进行封装

将服务信息注册到注册信息中去；(zookeeper、redis、Eureka )

 

在分布式架构中，断路器模式的作用也是类似的，当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延

  • Eureka：服务注册于发现
  • Feign：基于动态代理机制，根据注解和选择的机器，拼接请求 url 地址，发起请求
  • Ribbon：实现负载均衡，从一个服务的多台机器中选择一台
  • Hystrix：提供线程池，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
  • Zuul：网关管理，由 Zuul 网关转发请求给对应的服务

 1. 对JDBC访问数据库的代码做了封装，大大简化了数据访问层繁琐的重复性代码。

2. Hibernate是一个基于JDBC的主流持久化框架，是一个优秀的ORM实现。他很大程度的简化DAO层的编码工作

3. hibernate使用Java反射机制，而不是字节码增强程序来实现透明性。

4. hibernate的性能非常好，因为它是个轻量级框架。映射的灵活性很出色。它支持各种关系数据库，从一对一到多对多的各种复杂关系。

 

114.什么是 ORM 框架？

 ORM（Object Relation Mapping）对象关系映射

即通过类与数据库表的映射关系，将对象持久化到数据库中，

常用的有: Hibernate(Nhibernate)，iBATIS，mybatis，EclipseLink，JFinal

 

115.hibernate 中如何在控制台查看打印的 sql 语句？

 找到hibernate的配置文件– hibernate.cfg.xml
加入：
<property
name=”hibernate.show_sql”>true</property>

如果你用spring那么就要：
修改spring里面的配置文件：
…
<property
name=”hibernateProperties”>
<props>
<prop key =
“hibernate.dialect”>org.hibernate.dialect.MySQLDialect</prop>
<prop key =
“hibernate.show_sql”>false</prop>

116.hibernate 有几种查询方式？

 HQL, QBC（命名查询）, 以及使用原生SQL查询（SqlQuery）

117.hibernate 实体类可以被定义为 final 吗？

   是的，你可以将Hibernate的实体类定义为final类，但这种做法并不好。因为Hibernate会使用代理模式在延迟关联的情况下提高性能，如果你把实体类定义成final类之后，因为Java不允许对final类进行扩展，所以Hibernate就无法再使用代理了，如此一来就限制了使用可以提升性能的手段。
      不过，如果你的持久化类实现了一个接口而且在该接口中声明了所有定义于实体类中的所有public的方法的话，你就能够避免出现前面所说的不利后果。

118.在 hibernate 中使用 Integer 和 int 做映射有什么区别？

 Integer做映射和使用Int，似乎和hibernate没关系，实体新建的时候，int被初始化成0，Integer被初始化成null

119.hibernate 是如何工作的？

1.读取并解析配置
2.读取并解析映射信息，创建Session
Factory
3.打开Session
4.创建事务Transation
5.持久化操作
6.提交事务
7.关闭Session
8.关闭SesstionFactory

120.get()和 load()的区别？

 get和load的区别（小结）

*1. get是及时加载 会直接发送sql语句

 

load() 懒加载 用的时候才会加载

*2.get() 当查询的id不存在，会得到null

*load() 当查询的id不存在，会报错 org.hibernate.objectNotFoundException

*load在使用之前先使用user

3.get()

load()

关闭session之后还想要使用对象，这种时候load方法会报错

会报关于懒加载的错误

get（）方法效率快，不过占用内存，而load（）方法则节省空间

121.说一下 hibernate 的缓存机制？

 一级缓存，二级缓存
Session 的缓存被称为hibernate的第一级缓存。SessionFactory的外置缓存称为hibernate 的二级缓存。这两个缓存都位于持久层，它们存放的都是数据库数据的拷贝。SessionFactory的内置缓存存放元数据和预定义SQL，SessionFactory的内置缓存是只读缓存。
Hibernate的缓存包括Session的缓存和SessionFactory的缓存，其中SessionFactory的缓存又可以分为两类：内置缓存和外置缓存。Session的缓存是内置的，不能被卸载，也被称为Hibernate的第一级缓存。

122.hibernate 对象有哪些状态？

 1，Transient 瞬时
：对象刚new出来，还没设id，设了其他值。

2，Persistent 持久：调用了save()、saveOrUpdate()，就变成Persistent，有id

3，Detached  脱管 ： 当session
 close()完之后，变成Detached。

 

123.在 hibernate 中 getCurrentSession 和 openSession 的区别是什么？

 1.采用getCurrentSession()创建的Session会绑定到当前的线程中去，而采用OpenSession()则不会。

2.采用getCurrentSession()创建的Session在commit或rollback后会自动关闭，采用openSession()必须手动关闭。

3.采用getCurrentSession()需要在Hibernate.cfg.xml配置文件中加入如下配置：

1）如果是本地事物，及JDBC一个数据库：

<propety
name=”Hibernate.current_session_context_class”>thread</propety>

2）如果是全局事物，及jta事物、多个数据库资源或事物资源：

<propety
name=”Hibernate.current_session_context_class”>jta</propety>

124.hibernate 实体类必须要有无参构造函数吗？为什么？

 首先答案是肯定的。Hibernate框架会调用这个默认构造方法来构造实例对象，即Class类的newInstance方法 ，这个方法就是通过调用默认构造方法来创建实例对象的 。

当查询的时候返回的实体类是一个对象实例，是Hibernate动态通过反射生成的。反射的Class.forName(“className”).newInstance()需要对应的类提供一个无参构造方法，必须有个无参的构造方法将对象创建出来，单从Hibernate的角度讲 他是通过反射创建实体对象的 所以没有默认构造方法是不行的，另外Hibernate也可以通过有参的构造方法创建对象。

1.#将传入的数据都当成一个字符串，会对自动传入的数据加一个双引号。如：order by #user_id#，如果传入的值是111,那么解析成sql时的值为order by “111”, 如果传入的值是id，则解析成的sql为order by
“id”.

2.将传入的数据直接显示生成在sql中。如：orderby将传入的数据直接显示生成在sql中。如：orderbyuser_id$，如果传入的值是111,那么解析成sql时的值为order by
user_id, 如果传入的值是id，则解析成的sql为order by id.

3.#方式能够很大程度防止sql注入。

4.$方式无法防止Sql注入。

5.$方式一般用于传入数据库对象，例如传入表名.
　　
6.一般能用#的就别用$.

MyBatis排序时使用order by 动态参数时需要注意，用$而不是#

数组、sql语句，拦截器和RowBounds的方式

扩展：mybatis框架分页实现，有几种方式，最简单的就是利用原生的sql关键字limit来实现，还有一种就是利用interceptor来拼接sql，实现和limit一样的功能，再一个就是利用PageHelper来实现。这里讲解这三种常见的实现方式：

无论哪种实现方式，我们返回的结果，不能再使用List了，需要一个自定义对象Pager。

 

Mybatis可以通过传递RowBounds对象，来进行数据库数据的分页操作，然而遗憾的是，该分页操作是对ResultSet结果集进行分页，也就是人们常说的逻辑分页，而非物理分页。

Mybatis可以通过传递RowBounds对象，来进行数据库数据的分页操作，然而遗憾的是，该分页操作是对ResultSet结果集进行分页，这就是逻辑分页

物理分页性能是最好的。下面就是物理分页的结果

1. Sql中带有offset，limit参数，自己控制参数值，直接查询分页结果。

2. 使用第三方开发的Mybatis分页插件。

3. 修改Mybatis源码，给Sql追加自己的物理分页Subsql。

1：逻辑分页 内存开销比较大,在数据量比较小的情况下效率比物理分页高;在数据量很大的情况下,内存开销过大,容易内存溢出,不建议使用

2：物理分页 内存开销比较小,在数据量比较小的情况下效率比逻辑分页还是低,在数据量很大的情况下,建议使用物理分页

1)在mybatis 中默认没有使用延迟加载

2)怎么使用延迟加载呢?

　　在mybatis的配置中  配置一个setting的元素

　<!–
setting中的配置都是针对mybatis的运行行为进行配置的 –>

<settings><setting name=”lazyLoadingEnabled”
value=”true”/></settings>

3)在mybatis中,延迟加载也是使用动态代理完成的,但是在mybatis中,被代理的对象不是one方,而是many方本身.所以,默认情况下一旦我访问了这个延迟加载对象任何一个属性,都会触发这个延迟加载对象的加载(默认情况下e.getName();也会吃法dept的查询),这不是我们想要的结果,我们想要的是在需要dept的时候,才去查询dept对象.

<!– setting中的配置都是针对mybatis的运行行为进行配置的 –>

<settings><setting name=”lazyLoadingEnabled”
value=”true”/>

<!– 默认为true,代表只要访问延迟加载对象的任意一个属性,都会导致这个延迟加载对象的完全加载,设置为false,代表按需加载 –>

 <setting name=”aggressiveLazyLoading”
value=”false”/>

一级缓存

一级缓存是SqlSession级别的缓存。在操作数据库时需要构造sqlSession对象，在对象中有一个数据结构用于存储缓存数据。不同的sqlSession之间的缓存数据区域是互相不影响的。也就是他只能作用在同一个sqlSession中，不同的sqlSession中的缓存是互相不能读取的。

二级缓存

二级缓存是mapper级别的缓存，多个SqlSession去操作同一个Mapper的sql语句，多个SqlSession可以共用二级缓存，二级缓存是跨SqlSession的。

UserMapper有一个二级缓存区域（按namespace分），其它mapper也有自己的二级缓存区域（按namespace分）。每一个namespace的mapper都有一个二级缓存区域，两个mapper的namespace如果相同，这两个mapper执行sql查询到数据将存在相同的二级缓存区域中。

对于查询多commit少且用户对查询结果实时性要求不高，此时采用mybatis二级缓存技术降低数据库访问量，提高访问速度。

二级缓存性能不佳 会造成问题：

1）对该表的操作与查询都在同一个namespace下，其他的namespace如果有操作，就会发生数据的脏读。

2）对关联表的查询，关联的所有表的操作都必须在同一个namespace。

所以一般情况下 mybatis的二级缓存默认关闭不太使用

131.mybatis 和 hibernate 的区别有哪些？

Mybatis是通过sql语句得到对象 而hibernate是通过对象得到sql语句

<<< 相同点 >>>

　　1、Hibernate与MyBatis 都可以通过SessionFactoryBuilder 由 XML 配置文件生成SessionFactory, 然后再由SessionFactory 生成Session ，最后又 Session 来开启执行事务和SQL语句。 Session，
SessionFactory ，SessionFactory的生命周期都是差不多的。

　　2、二者都支持JDBC和JTA事务处理。

<<< 不同点 >>>

　　1、MyBatis 可以进行更加细致的优化，可以选择性的查询需要的字段。同时对多张表操作时，MyBatis更加具有优势。

　　2、MyBatis容易掌握，Hibernate
比较难以掌握，比如Hibernate虽然可以不写sql语句完成增删改查的操作，却需要按照既定的命名格式命名，学习成本高。

　　3、Hibernate 对增删改查对象维护更加容易，效率也更高。

　　4、Hibernate的数据库移植性更加好，可以通过修改方言完成数据库的更改，Hibernate将根据方言自动生成符合的SQL语句。MyBatis的数据库移植性不好，更改完数据库后需要去一个一个的更改每条SQL语句，耗时耗力。

　　5、Hibernate有更好的二级缓存机制， 可以使用第三方缓存。MyBatis自身提供的缓存机制不够方便。

 

SimpleExecutor、ReuseExecutor、BatchExecutor。

SimpleExecutor：每执行一次update或select，就开启一个Statement对象，用完立刻关闭Statement对象。

ReuseExecutor：执行update或select，以sql作为key查找Statement对象，存在就使用，不存在就创建，用完后，不关闭Statement对象，而是放置于Map内，供下一次使用。简言之，就是重复使用Statement对象。

BatchExecutor：执行update（没有select，JDBC批处理不支持select），将所有sql都添加到批处理中（addBatch()），等待统一执行（executeBatch()），它缓存了多个Statement对象，每个Statement对象都是addBatch()完毕后，等待逐一执行executeBatch()批处理。与JDBC批处理相同。

作用范围：Executor的这些特点，都严格限制在SqlSession生命周期范围内。

分页插件的基本原理是使用Mybatis提供的插件接口，实现自定义插件，在插件的拦截方法内拦截待执行的sql，然后重写sql，根据dialect方言，添加对应的物理分页语句和物理分页参数

1. 编写Interceptor的实现类 2. 使用@Intercepts注解完成插件签名 说明插件的拦截四大对象之一的哪一个对象的哪一个方法 3. 将写好的插件注册到全局配置文件中4大对象。

1.Executor (update, query, flushStatements, commit, rollback,
getTransaction, close, isClosed)          –执行sql

2.ParameterHandler (getParameterObject, setParameters)     
               –获取、设置参数

3.ResultSetHandler (handleResultSets, handleOutputParameters)   
      –处理结果集

4.StatementHandler (prepare, parameterize, batch, update, query) 
        –记录sql

  相同点：屏蔽jdbc api的底层访问细节，使用我们不用与jdbc api打交道，就可以访问数据。jdbc api编程流程固定，还将sql语句与java代码混杂在了一起，经常需要拼凑sql语句，细节很繁琐。

mybatis的好处：屏蔽jdbc api的底层访问细节；将sql语句与java代码进行分离;提供了将结果集自动封装称为实体对象和对象的集合的功能，queryForList返回对象集合，用queryForObject返回单个对象；提供了自动将实体对象的属性传递给sql语句的参数。

Hibernate是一个全自动的orm映射工具，它可以自动生成sql语句,mybatis需要我们自己在xml配置文件中写sql语句，hibernate要比mybatis功能负责和强大很多。因为hibernate自动生成sql语句，我们无法控制该语句，我们就无法去写特定的高效率的sql。对于一些不太复杂的sql查询，hibernate可以很好帮我们完成，但是，对于特别复杂的查询，hibernate就很难适应了，这时候用mybatis就是不错的选择，因为mybatis还是由我们自己写sql语句。

 

 

 

 

 

1.提供了事务的功能。2.通过将 channel 设置为 confirm（确认）模式。

消息持久化、ACK确认机制、设置集群镜像模式、消息补偿机制

  1. 声明队列必须设置持久化 durable 设置为 true.
  2. 消息推送投递模式必须设置持久化，deliveryMode 设置为 2（持久）。
  3. 消息已经到达持久化交换器。
  4. 消息已经到达持久化队列。
  5. 以上四个条件都满足才能保证消息持久化成功。

持久化的缺地就是降低了服务器的吞吐量，因为使用的是磁盘而非内存存储，从而降低了吞吐量。可尽量使用 ssd 硬盘来缓解吞吐量的问题。

  1. 持久化的缺地就是降低了服务器的吞吐量，
  2. 因为使用的是磁盘而非内存存储，
  3. 从而降低了吞吐量。可尽量使用 ssd 硬盘来缓解吞吐量的问题。
  4. 通过消息过期后进入死信交换器，再由交换器转发到延迟消费队列，实现延迟功能；
  5. 使用
    RabbitMQ-delayed-message-exchange 插件实现延迟功能
  6. 高可用：某个服务器出现问题，整个 RabbitMQ 还可以继续使用；
  7. 高容量：集群可以承载更多的消息量
  8.  磁盘节点：消息会存储到磁盘。
    1. 内存节点：消息都存储在内存中，重启服务器消息丢失，性能高于磁盘类型

148.rabbitmq 集群搭建需要注意哪些问题？
1.各节点之间使用“–link”连接，此属性不能忽略。

2.各节点使用的 erlang cookie
值必须相同，此值相当于“秘钥”的功能，用于各节点的认证。

3.整个集群中必须包含一个磁盘节点。

不是，原因有以下两个：

  1. 存储空间的考虑：如果每个节点都拥有所有队列的完全拷贝，这样新增节点不但没有新增存储空间，反而增加了更多的冗余数据；

 

  1. 性能的考虑：如果每条消息都需要完整拷贝到每一个集群节点，那新增节点并没有提升处理消息的能力，最多是保持和单节点相同的性能甚至是更糟。

如果唯一磁盘的磁盘节点崩溃了，不能进行以下操作：

  1. 不能创建队列
  2. 不能创建交换器
  3. 不能创建绑定
  4. 不能添加用户
  5. 不能更改权限
  6. 不能添加和删除集群节点
  7. 唯一磁盘节点崩溃了，集群是可以保持运行的，但你不能更改任何东西
  8. RabbitMQ 对集群的停止的顺序是有要求的，应该先关闭内存节点，最后再关闭磁盘节点。如果顺序恰好相反的话，可能会造成消息的丢失。

 

kafka 不能脱离 zookeeper 单独使用，因为 kafka 使用 zookeeper 管理和协调 kafka 的节点服务器。

153.kafka 有几种数据保留的策略？
kafka 有两种数据保存策略： 按照过期时间保留、按照存储的消息大小保留。

这个时候 kafka 会执行数据清除工作，时间和大小不论那个满足条件，都会清空数据。

cpu 性能瓶颈、磁盘读写瓶颈、网络瓶颈

集群的数量不是越多越好，最好不要超过 7 个、因为节点越多，消息复制需要的时间就越长，整个群组的吞吐量就越低。、集群数量最好是单数，因为超过一半故障集群就不能用了，设置为单数容错率更高

ZooKeeper由雅虎研究院开发，是Google Chubby的开源实现，后来托管到Apache，于2010年11月正式成为Apache的顶级项目。

ZooKeeper是一个经典的分布式数据一致性解决方案，致力于为分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务。

分布式应用程序可以基于ZooKeeper实现数据发布与订阅、负载均衡、命名服务、分布式协调与通知、集群管理、Leader选举、分布式锁、分布式队列等功能。

 

单机模式、集群模式和伪集群模式

160.zookeeper 怎么保证主从节点的状态同步？

 

  1. 在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，
  2.  
  3. 其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，所以就需要主节点。

 

可以继续使用，单数服务器只要没超过一半的服务器宕机就可以继续使用。


  1. 客户端端会对某个 znode 建立一个 watcher 事件，
  2.  
  3. 当该 znode 发生变化时，这些客户端会收到 zookeeper 的通知，
  4.  
  5. 然后客户端可以根据 znode 变化来做出业务上的改变。

 

  • 第一范式：强调的是列的原子性，即数据库表的每一列都是不可分割的原子数据项。
  • 第二范式：要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。
  • 第三范式：任何非主属性不依赖于其它非主属性。
  • 表类型如果是 MyISAM ，那 id 就是 8。
  • 表类型如果是 InnoDB，那 id 就是 6。

使用 select version()
获取当前 MySQL 数据库版本。

创建索引 最多五个   

select version()

  • Atomicity（原子性）：一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。
  • Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。
  • Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
  • Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
  • char(n) ：固定长度类型，比如订阅 char(10)，当你输入”abc”三个字符的时候，它们占的空间还是 10 个字节，其他 7 个是空字节。

chat 优点：效率高；缺点：占用空间；适用场景：存储密码的 md5 值，固定长度的，使用 char 非常合适。

  • varchar(n) ：可变长度，存储的值是每个值占用的字节再加上一个用来记录其长度的字节的长度。

所以，从空间上考虑 varcahr 比较合适；从效率上考虑 char 比较合适，二者使用需要权衡

  • float 最多可以存储 8 位的十进制数，并在内存中占 4 字节。
  • double 最可可以存储 16 位的十进制数，并在内存中占 8 字节。

　　内连接关键字：inner join；左连接：left join；右连接：right join。 内连接是把匹配的关联数据显示出来；左连接是左边的表全部显示出来，右边的表显示出符合条件的数据；右连接正好相反

　　索引是满足某种特定查找算法的数据结构，而这些数据结构会以某种方式指向数据，从而实现高效查找数据。 具体来说 MySQL 中的索引，不同的数据引擎实现有所不同，但目前主流的数据库引擎的索引都是 B+ 树实现的，B+ 树的搜索效率，可以到达二分法的性能，找到数据区域之后就找到了完整的数据结构了，所有索引的性能也是更好的

使用 explain 查看 SQL 是如何执行查询语句的，从而分析你的索引是否满足需求。

explain 语法：

explain select * from table where type=1

MySQL 的事务隔离是在 MySQL. ini 配置文件里添加的，在文件的最后添加：

transaction-isolation = REPEATABLE-READ

可用的配置值：READ-UNCOMMITTED、READ-COMMITTED、REPEATABLE-READ、SERIALIZABLE。

  • READ-UNCOMMITTED：未提交读，最低隔离级别、事务未提交前，就可被其他事务读取（会出现幻读、脏读、不可重复读）。
  • READ-COMMITTED：提交读，一个事务提交后才能被其他事务读取到（会造成幻读、不可重复读）。
  • REPEATABLE-READ：可重复读，默认级别，保证多次读取同一个数据时，其值都和事务开始时候的内容是一致，禁止读取到别的事务未提交的数据（会造成幻读）。
  • SERIALIZABLE：序列化，代价最高最可靠的隔离级别，该隔离级别能防止脏读、不可重复读、幻读。

脏读 ：表示一个事务能够读取另一个事务中还未提交的数据。比如，某个事务尝试插入记录 A，此时该事务还未提交，然后另一个事务尝试读取到了记录 A。

不可重复读 ：是指在一个事务内，多次读同一数据。

幻读 ：指同一个事务内多次查询返回的结果集不一样。比如同一个事务 A 第一次查询时候有 n 条记录，但是第二次同等条件下查询却有 n+1 条记录，这就好像产生了幻觉。发生幻读的原因也是另外一个事务新增或者删除或者修改了第一个事务结果集里面的数据，同一个记录的数据内容被修改了，所有数据行的记录就变多或者变少了

  • InnoDB 引擎：InnoDB 引擎提供了对数据库 acid 事务的支持，并且还提供了行级锁和外键的约束，它的设计的目标就是处理大数据容量的数据库系统。MySQL 运行的时候，InnoDB 会在内存中建立缓冲池，用于缓冲数据和索引。但是该引擎是不支持全文搜索，同时启动也比较的慢，它是不会保存表的行数的，所以当进行 select count(*) from table 指令的时候，需要进行扫描全表。由于锁的粒度小，写操作是不会锁定全表的,所以在并发度较高的场景下使用会提升效率
  • MyIASM 引擎：MySQL 的默认引擎，但不提供事务的支持，也不支持行级锁和外键。因此当执行插入和更新语句时，即执行写操作的时候需要锁定这个表，所以会导致效率会降低。不过和 InnoDB 不同的是，MyIASM 引擎是保存了表的行数，于是当进行 select count(*) from table 语句时，可以直接的读取已经保存的值而不需要进行扫描全表。所以，如果表的读操作远远多于写操作时，并且不需要事务的支持的，可以将 MyIASM 作为数据库引擎的首选

MyISAM 只支持表锁，InnoDB 支持表锁和行锁，默认为行锁

  • 表级锁：开销小，加锁快，不会出现死锁。锁定粒度大，发生锁冲突的概率最高，并发量最低
  • 行级锁：开销大，加锁慢，会出现死锁。锁力度小，发生锁冲突的概率小，并发度最高
  • 乐观锁：每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在提交更新的时候会判断一下在此期间别人有没有去更新这个数据
  • 悲观锁：每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻止，直到这个锁被释放

　　数据库的乐观锁需要自己实现，在表里面添加一个 version 字段，每次修改成功值加 1，这样每次修改的时候先对比一下，自己拥有的 version 和数据库现在的 version 是否一致，如果不一致就不修改，这样就实现了乐观锁

  • 使用 show processlist 命令查看当前所有连接信息
  • 使用 explain 命令查询 SQL 语句执行计划
  • 开启慢查询日志，查看慢查询的 SQL
  • 为搜索字段创建索引
  • 避免使用 select *，列出需要查询的字段
  • 垂直分割分表
  • 选择正确的存储引擎

表的设计合理化(符合3NF)

添加适当索引(index) [四种: 普通索引、主键索引、唯一索引unique、全文索引]

SQL语句优化

分表技术(水平分割、垂直分割)

读写[写: update/delete/add]分离

存储过程 [模块化编程，可以提高速度]

对mysql配置优化 [配置最大并发数my.ini,
调整缓存大小 ]

mysql服务器硬件升级

定时的去清除不需要的数据,定时进行碎片整理(MyISAM)

 

为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。

 

第一范式：1NF是对属性的原子性约束，要求属性(列)具有原子性，不可再分解；(只要是关系型数据库都满足1NF)

第二范式：2NF是对记录的惟一性约束，表中的记录是唯一的, 就满足2NF, 通常我们设计一个主键来实现，主键不能包含业务逻辑。

第三范式：3NF是对字段冗余性的约束，它要求字段没有冗余。 没有冗余的数据库设计可以做到。

但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：
在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。

 

  MySQL默认10秒内没有响应SQL结果,则为慢查询

可以去修改MySQL慢查询默认时间

 

–查询慢查询时间

show variables like \’long_query_time\’;

–修改慢查询时间

set long_query_time=1; —但是重启mysql之后，long_query_time依然是my.ini中的值

 

 

在默认情况下，我们的mysql不会记录慢查询，需要在启动mysql时候，指定记录慢查询才可以

bin\mysqld.exe –safe-mode  –slow-query-log [mysql5.5 可以在my.ini指定]（安全模式启动，数据库将操作写入日志，以备恢复）

bin\mysqld.exe –log-slow-queries=d:/abc.log
[低版本mysql5.0可以在my.ini指定]

先关闭mysql,再启动, 如果启用了慢查询日志，默认把这个文件放在

my.ini 文件中记录的位置

#Path to the database root

datadir=” C:/ProgramData/MySQL/MySQL
Server 5.5/Data/”

 

索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。

 

 

主键索引

主键是一种唯一性索引，但它必须指定为“PRIMARY KEY”。如果你曾经用过AUTO_INCREMENT类型的列，你可能已经熟悉主键之类的概念了。主键一般在创建表的时候指定，例如“CREATE TABLE tablename ( […], PRIMARY KEY (列的列表) ); ”。但是，我们也可以通过修改表的方式加入主键，例如“ALTER TABLE
tablename ADD PRIMARY KEY (列的列表); ”。每个表只能有一个主键。 

 

创建主键索引

主键是一种唯一性索引，但它必须指定为“PRIMARY KEY”。如果你曾经用过AUTO_INCREMENT类型的列，你可能已经熟悉主键之类的概念了。主键一般在创建表的时候指定，例如“CREATE TABLE tablename ( […], PRIMARY KEY (列的列表) ); ”。但是，我们也可以通过修改表的方式加入主键，例如“ALTER TABLE
tablename ADD PRIMARY KEY (列的列表); ”。每个表只能有一个主键。 

当一张表，把某个列设为主键的时候，则该列就是主键索引

create table aaa

(id int unsigned
primary key auto_increment ,

name varchar(32) not
null default \’\’);

这是id 列就是主键索引.

create table bbb (id
int , name varchar(32) not null default \’\’);

如果你创建表时，没有指定主键索引，也可以在创建表后，在添加, 指令:

实例:

alter table 表名 add primary key (列名);

删除主键索引

alter table articles
drop primary key;

 

查询索引

desc 
表名;   不能显示索引名称

show index from 表名

show keys from 表名

 

全文索引

错误用法:

select * from articles where body like
\’%mysql%\’; 错误用法 索引不会生效

正确用法:

select * from articles where
match(title,body) against ( \’database\’)

说明:

  1. 在mysql中fulltext
    索引只针对 myisam生效
  2. mysql自己提供的fulltext针对英文生效->sphinx (coreseek) 技术处理中文
  3. 使用方法是 match(字段名..) against(‘关键字’)
  4. 全文索引：停止词,  因为在一个文本中，创建索引是一个无穷大的数，因此，对一些常用词和字符，就不会创建，这些词，称为停止词.比如（a，b，mysql，the）

mysql> select
match(title,body) against (\’database\’) from articles;（输出的是每行和database的匹配度）

 

唯一索引

这种索引和前面的“普通索引”基本相同，但有一个区别：索引列的所有值都只能出现一次，即必须唯一。唯一性索引可以用以下几种方式创建： 

创建索引，例如CREATE
UNIQUE INDEX <索引的名字> ON tablename (列的列表)； 

修改表，例如ALTER
TABLE tablename ADD UNIQUE [索引的名字] (列的列表)； 

创建表的时候指定索引，例如CREATE
TABLE tablename ( […], UNIQUE [索引的名字] (列的列表) )； 

 

普通索引

 普通索引（由关键字KEY或INDEX定义的索引）的唯一任务是加快对数据的访问速度。因此，应该只为那些最经常出现在查询条件（WHEREcolumn=）或排序条件（ORDERBYcolumn）中的数据列创建索引。只要有可能，就应该选择一个数据最整齐、最紧凑的数据列（如一个整数类型的数据列）来创建索引。

 

create table ccc(

id int unsigned,

name varchar(32)

)

create index 索引名 on 表 (列1,列名2);

 

 

索引的实现原理

 

 

数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用 B 树及其变种 B+ 树。

在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。

为表设置索引要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。

 

上图展示了一种可能的索引方式。左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址（注意逻辑上相邻的记录在磁盘上也并不是一定物理相邻的）。为了加快 Col2 的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在 O(log2n)的复杂度内获取到相应数据。

创建索引可以大大提高系统的性能。

第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。

第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。

第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。

第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。

第五，通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。

也许会有人要问：增加索引有如此多的优点，为什么不对表中的每一个列创建一个索引呢？因为，增加索引也有许多不利的方面。

第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。

第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。

第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。

索引是建立在数据库表中的某些列的上面。在创建索引的时候，应该考虑在哪些列上可以创建索引，在哪些列上不能创建索引。一般来说，应该在这些列上创建索引：在经常需要搜索的列上，可以加快搜索的速度；在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；在经常使用在 WHERE 子句中的列上面创建索引，加快条件的判断速度。

同样，对于有些列不应该创建索引。一般来说，不应该创建索引的的这些列具有下列特点：

第一，对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。

第二，对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。

第三，对于那些定义为
text, image 和 bit 数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。

第四，当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改性能远远大于检索性能时，不应该创建索引。

根据数据库的功能，可以在数据库设计器中创建三种索引：唯一索引、主键索引和聚集索引。

唯一索引

唯一索引是不允许其中任何两行具有相同索引值的索引。

当现有数据中存在重复的键值时，大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。例如，如果在 employee 表中职员的姓(lname)上创建了唯一索引，则任何两个员工都不能同姓。主键索引数据库表经常有一列或列组合，其值唯一标识表中的每一行。该列称为表的主键。在数据库关系图中为表定义主键将自动创建主键索引，主键索引是唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时，它还允许对数据的快速访问。聚集索引在聚集索引中，表中行的物理顺序与键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引。

如果某索引不是聚集索引，则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比，聚集索引通常提供更快的数据访问速度。

局部性原理与磁盘预读

由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分分之一，因此为了提高效率，要尽量减少磁盘 I/O。为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。程序运行期间所需要的数据通常比较集中。

由于磁盘顺序读取的效率很高（不需要寻道时间，只需很少的旋转时间），因此对于具有局部性的程序来说，预读可以提高 I/O 效率。

预读的长度一般为页（page）的整倍数。页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页得大小通常为 4k），主存和磁盘以页为单位交换数据。当程序要读取的数据不在主存中时，会触发一个缺页异常，此时系统会向磁盘发出读盘信号，磁盘会找到数据的起始位置并向后连续读取一页或几页载入内存中，然后异常返回，程序继续运行。

B-/+Tree 索引的性能分析

到这里终于可以分析
B-/+Tree 索引的性能了。

上文说过一般使用磁盘 I/O
次数评价索引结构的优劣。先从 B-Tree 分析，根据
B-Tree 的定义，可知检索一次最多需要访问 h 个节点。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次 I/O 就可以完全载入。为了达到这个目的，在实际实现 B-Tree 还需要使用如下技巧：

每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，加之计算机存储分配都是按页对齐的，就实现了一个 node 只需一次 I/O。

B-Tree 中一次检索最多需要 h-1 次
I/O（根节点常驻内存），渐进复杂度为 O(h)=O(logdN)。一般实际应用中，出度 d 是非常大的数字，通常超过 100，因此 h 非常小（通常不超过
3）。

而红黑树这种结构，h 明显要深的多。由于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，所以红黑树的 I/O 渐进复杂度也为 O(h)，效率明显比 B-Tree 差很多。

综上所述，用
B-Tree 作为索引结构效率是非常高的。

应该花时间学习 B-树和 B+ 树数据结构

=============================================================================================================

1）B 树

B 树中每个节点包含了键值和键值对于的数据对象存放地址指针，所以成功搜索一个对象可以不用到达树的叶节点。

成功搜索包括节点内搜索和沿某一路径的搜索，成功搜索时间取决于关键码所在的层次以及节点内关键码的数量。

在 B 树中查找给定关键字的方法是：首先把根结点取来，在根结点所包含的关键字 K1,…,kj 查找给定的关键字（可用顺序查找或二分查找法），若找到等于给定值的关键字，则查找成功；否则，一定可以确定要查的关键字在某个 Ki 或 Ki+1 之间，于是取 Pi
所指的下一层索引节点块继续查找，直到找到，或指针 Pi 为空时查找失败。

2）B+ 树

B+ 树非叶节点中存放的关键码并不指示数据对象的地址指针，非也节点只是索引部分。所有的叶节点在同一层上，包含了全部关键码和相应数据对象的存放地址指针，且叶节点按关键码从小到大顺序链接。如果实际数据对象按加入的顺序存储而不是按关键码次数存储的话，叶节点的索引必须是稠密索引，若实际数据存储按关键码次序存放的话，叶节点索引时稀疏索引。

B+ 树有 2 个头指针，一个是树的根节点，一个是最小关键码的叶节点。

所以 B+ 树有两种搜索方法：

一种是按叶节点自己拉起的链表顺序搜索。

一种是从根节点开始搜索，和
B 树类似，不过如果非叶节点的关键码等于给定值，搜索并不停止，而是继续沿右指针，一直查到叶节点上的关键码。所以无论搜索是否成功，都将走完树的所有层。

B+ 树中，数据对象的插入和删除仅在叶节点上进行。

这两种处理索引的数据结构的不同之处：
a，B 树中同一键值不会出现多次，并且它有可能出现在叶结点，也有可能出现在非叶结点中。而 B+ 树的键一定会出现在叶结点中，并且有可能在非叶结点中也有可能重复出现，以维持 B+
树的平衡。
b，因为 B 树键位置不定，且在整个树结构中只出现一次，虽然可以节省存储空间，但使得在插入、删除操作复杂度明显增加。B+ 树相比来说是一种较好的折中。
c，B 树的查询效率与键在树中的位置有关，最大时间复杂度与
B+ 树相同(在叶结点的时候)，最小时间复杂度为 1(在根结点的时候)。而 B+ 树的时候复杂度对某建成的树是固定的。可以扫描2的次方。

占用磁盘空间

对DML(update、delete、insert)语句的效率影响

增删改会对索引影响，因为索引要重新整理。

 

存储引擎

允许的索引类型

myisam

btree

innodb

btree

memory/yeap

Hash,btree

 

 

①   
查询作为查询条件字段应该创建索引

②   
唯一性太差的字段不适合单独创建索引,即使频繁

Select * from emp where sex=’男’

③   
频繁更新字段，也不要定义索引。

④   
不会出现在where语句的字段不要创建索引

 

总结:满处一下条件的字段，才应该创建索引

①  肯定在where条件经常使用

②  该字段的内容不是唯一的几个值

③  字段内容不是频繁变化

 

创建主键索引

alter table 表名 add primary key (列名);

创建一个联合索引

alter
table dept add index my_ind (dname,loc); // 
dname 左边的列,loc就是右边的列

注意:

1.对于创建的多列索引，如果不是使用第一部分，则不会创建索引。

explain select *
from dept where loc=\’aaa\’\G

就不会使用到索引

2.模糊查询在like前面有百分号开头会失效。

3. 如果条件中有or，即使其中有条件带索引也不会使用。换言之，就是要求使用的所有字段，都必须建立索引, 我们建议大家尽量避免使用or 关键字

4.如果列类型是字符串，那一定要在条件中将数据使用引号引用起来。否则不使用索引。(添加时,字符串必须’’), 也就是，如果列是字符串类型，就一定要用 ‘’ 把他包括起来.

5.如果mysql估计使用全表扫描要比使用索引快，则不使用索引。

 

 

show status like ‘handler_read%’;

 

大家可以注意：
handler_read_key:这个值越高越好，越高表示使用索引查询到的次数。

handler_read_rnd_next:这个值越高，说明查询低效。

 

①  使用group by 分组查询是，默认分组后，还会排序，可能会降低速度，

在group by 后面增加 order by null 就可以防止排序.

explain select *
from emp  group by deptno order by null;

②  有些情况下，可以使用连接来替代子查询。因为使用join，MySQL不需要在内存中创建临时表。

select * from dept, emp where
dept.deptno=emp.deptno; [简单处理方式]

select * from dept left join emp on
dept.deptno=emp.deptno;  [左外连接，更ok!]

 

 

③  对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引

应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

最好不要给数据库留 NULL，尽可能的使用 NOT NULL 填充数据库.

备注、描述、评论之类的可以设置为 NULL，其他的，最好不要使用 NULL。

不要以为 NULL 不需要空间，比如：char(100) 型，在字段建立时，空间就固定了， 不管是否插入值（NULL 也包含在内），都是占用 100 个字符的空间的，如果是 varchar 这样的变长字段， null 不占用空间。

可以在 num 上设置默认值
0，确保表中 num 列没有 null 值，然后这样查询：

select id from t where num = 0

更多mysql sql语句调优查看http://bbs.itmayiedu.com/article/1511164574773

 

使用的存储引擎 myisam
/ innodb/ memory

myisam 存储: 如果表对事务要求不高，同时是以查询和添加为主的，我们考虑使用myisam存储引擎. ,比如 bbs 中的
发帖表，回复表.

INNODB 存储: 对事务要求高，保存的数据都是重要数据，我们建议使用INNODB,比如订单表，账号表.

MyISAM 和 INNODB的区别

1. 事务安全（MyISAM不支持事务，INNODB支持事务）

2. 查询和添加速度（MyISAM批量插入速度快）

3. 支持全文索引（MyISAM支持全文索引，INNODB不支持全文索引）

4. 锁机制（MyISAM时表锁，innodb是行锁）

5. 外键 MyISAM 不支持外键， INNODB支持外键. (在PHP开发中，通常不设置外键，通常是在程序中保证数据的一致)

Memory 存储，比如我们数据变化频繁，不需要入库，同时又频繁的查询和修改，我们考虑使用memory,
速度极快. （如果mysql重启的话，数据就不存在了）

 

 

 

Myisam注意事项

如果你的数据库的存储引擎是myisam,请一定记住要定时进行碎片整理

举例说明:

create table
test100(id int unsigned ,name varchar(32))engine=myisam;

insert into test100
values(1,’aaaaa’);

insert into test100
values(2,’bbbb’);

insert into test100
values(3,’ccccc’);

我们应该定义对myisam进行整理

optimize table
test100;

 

手动方式

cmd控制台:

在环境变量中配置mysql环境变量

mysqldump –u -账号 –密码 数据库 [表名1 表名2..]  > 文件路径

案例: mysqldump -u -root root test > d:\temp.sql

 

比如: 把temp数据库备份到
d:\temp.bak

mysqldump -u root -proot test > f:\temp.bak

如果你希望备份是，数据库的某几张表

mysqldump -u root -proot test dept > f:\temp.dept.sql

 

如何使用备份文件恢复我们的数据.

mysql控制台

source d:\temp.dept.bak

自动方式

把备份数据库的指令，写入到
bat文件, 然后通过任务管理器去定时调用 bat文件.

mytask.bat 内容是:

@echo off

F:\path\mysqlanzhuang\bin\mysqldump -u
root -proot test dept > f:\temp.dept.sql

创建执行计划任务执行脚本。

 

 

垂直拆分

垂直拆分就是要把表按模块划分到不同数据库表中（当然原则还是不破坏第三范式），这种拆分在大型网站的演变过程中是很常见的。当一个网站还在很小的时候，只有小量的人来开发和维护，各模块和表都在一起，当网站不断丰富和壮大的时候，也会变成多个子系统来支撑，这时就有按模块和功能把表划分出来的需求。其实，相对于垂直切分更进一步的是服务化改造，说得简单就是要把原来强耦合的系统拆分成多个弱耦合的服务，通过服务间的调用来满足业务需求看，因此表拆出来后要通过服务的形式暴露出去，而不是直接调用不同模块的表，淘宝在架构不断演变过程，最重要的一环就是服务化改造，把用户、交易、店铺、宝贝这些核心的概念抽取成独立的服务，也非常有利于进行局部的优化和治理，保障核心模块的稳定性

垂直拆分用于分布式场景。

 

水平拆分

上面谈到垂直切分只是把表按模块划分到不同数据库，但没有解决单表大数据量的问题，而水平切分就是要把一个表按照某种规则把数据划分到不同表或数据库里。例如像计费系统，通过按时间来划分表就比较合适，因为系统都是处理某一时间段的数据。而像SaaS应用，通过按用户维度来划分数据比较合适，因为用户与用户之间的隔离的，一般不存在处理多个用户数据的情况，简单的按user_id范围来水平切分

通俗理解：水平拆分行，行数据拆分到不同表中， 垂直拆分列，表数据拆分到不同表中

 

水平分割案例

思路:在大型电商系统中，每天的会员人数不断的增加。达到一定瓶颈后如何优化查询。

可能大家会想到索引，万一用户量达到上亿级别，如何进行优化呢？

使用水平分割拆分数据库表。

 

如何使用水平拆分数据库

使用水平分割拆分表，具体根据业务需求，有的按照注册时间、取摸、账号规则、年份等。

 

使用取摸方式分表

首先我创建三张表 user0 / user1 /user2 , 然后我再创建 uuid表，该表的作用就是提供自增的id。

 

create table user0(

id int unsigned primary key ,

name varchar(32) not null default \’\’,

pwd  varchar(32) not
null default \’\’)

engine=myisam charset utf8;

 

create table user1(

id int unsigned primary key ,

name varchar(32) not null default \’\’,

pwd  varchar(32) not
null default \’\’)

engine=myisam charset utf8;

 

create table user2(

id int unsigned primary key ,

name varchar(32) not null default \’\’,

pwd  varchar(32) not
null default \’\’)

engine=myisam charset utf8;

 

 

create table uuid(

id int unsigned primary key auto_increment)engine=myisam
charset utf8;

 

创建一个demo项目

POM文件

     <parent>

          <groupId>org.springframework.boot</groupId>

          <artifactId>spring-boot-starter-parent</artifactId>

          <version>1.3.3.RELEASE</version>

     </parent>

     <dependencies>

          <dependency>

               <groupId>org.springframework.boot</groupId>

               <artifactId>spring-boot-starter-jdbc</artifactId>

          </dependency>

          <dependency>

               <groupId>org.springframework.boot</groupId>

               <artifactId>spring-boot-starter</artifactId>

          </dependency>

          <dependency>

               <groupId>org.springframework.boot</groupId>

               <artifactId>spring-boot-starter-test</artifactId>

               <scope>test</scope>

          </dependency>

          <dependency>

               <groupId>mysql</groupId>

               <artifactId>mysql-connector-java</artifactId>

          </dependency>

          <dependency>

               <groupId>org.springframework.boot</groupId>

               <artifactId>spring-boot-starter-web</artifactId>

          </dependency>

     </dependencies>

Service代码

@Service

publicclass UserService {

 

     @Autowired

     private JdbcTemplate jdbcTemplate;

 

     public String regit(String name, String pwd) {

          // 1.先获取到自定增长ID

          String idInsertSQL = “INSERT
INTO uuid VALUES (NULL);”;

          jdbcTemplate.update(idInsertSQL);

          Long insertId = jdbcTemplate.queryForObject(“select
last_insert_id()”, Long.class);

          // 2.判断存储表名称

          String tableName = “user” + insertId % 3;

          // 3.注册数据

          String insertUserSql = “INSERT
INTO “ + tableName + ” VALUES (\'” + insertId + “\’,\'” + name + “\’,\'” + pwd

                    +
“\’);”;

          System.out.println(“insertUserSql:” + insertUserSql);

          jdbcTemplate.update(insertUserSql);

          return“success”;

     }

 

     public String get(Long id) {

          String tableName = “user” + id % 3;

          String sql = “select
name from “ + tableName + ”  where id=”+id;

          System.out.println(“SQL:” + sql);

          String name = jdbcTemplate.queryForObject(sql, String.class);

          returnname;

     }

 

}

 

Controller

@RestController

publicclass UserController {

     @Autowired

     private UserService userService;

 

     @RequestMapping(“/regit”)

     public String regit(String name, String pwd) {

          returnuserService.regit(name, pwd);

     }

 

     @RequestMapping(“/get”)

     public String get(Long id) {

          String name = userService.get(id);

          returnname;

     }

 

}

 

 

在数据库集群架构中，让主库负责处理事务性查询，而从库只负责处理select查询，让两者分工明确达到提高数据库整体读写性能。当然，主数据库另外一个功能就是负责将事务性查询导致的数据变更同步到从库中，也就是写操作。

 

 1）分摊服务器压力，提高机器的系统处理效率

    读写分离适用于读远比写的场景，如果有一台服务器，当select很多时，update和delete会被这些select访问中的数据堵塞，等待select结束，并发性能并不高，而主从只负责各自的写和读，极大程度的缓解X锁和S锁争用；

   假如我们有1主3从，不考虑上述1中提到的从库单方面设置，假设现在1分钟内有10条写入，150条读取。那么，1主3从相当于共计40条写入，而读取总数没变，因此平均下来每台服务器承担了10条写入和50条读取（主库不承担读取操作）。因此，虽然写入没变，但是读取大大分摊了，提高了系统性能。另外，当读取被分摊后，又间接提高了写入的性能。所以，总体性能提高了，说白了就是拿机器和带宽换性能；

  2）增加冗余，提高服务可用性，当一台数据库服务器宕机后可以调整另外一台从库以最快速度恢复服务

 

 依赖于二进制日志，binary-log.

 二进制日志中记录引起数据库发生改变的语句

 
Insert 、delete、update、create table

 

Scale Out是指Application可以在水平方向上扩展。一般对数据中心的应用而言，Scale out指的是当添加更多的机器时，应用仍然可以很好的利用这些机器的资源来提升自己的效率从而达到很好的扩展性。

Scale Up是指Application可以在垂直方向上扩展。一般对单台机器而言，Scale Up值得是当某个计算节点（机器）添加更多的CPU Cores，存储设备，使用更大的内存时，应用可以很充分的利用这些资源来提升自己的效率从而达到很好的扩展性。

 

 

解决问题

数据如何不被丢失

备份

读写分离

数据库负载均衡

高可用

 

环境搭建

  1. 准备环境

两台windows操作系统 ip分别为: 172.27.185.1(主)、172.27.185.2(从)

  1. 连接到主服务(172.27.185.1)服务器上，给从节点分配账号权限。

GRANT REPLICATION SLAVE ON *.* TO
\’root\’@\’172.27.185.2\’ IDENTIFIED BY \’root\’;

  1. 在主服务my.ini文件新增

server-id=200

log-bin=mysql-bin

relay-log=relay-bin

relay-log-index=relay-bin-index

重启mysql服务

  1. 在从服务my.ini文件新增

server-id = 210

replicate-do-db =itmayiedu #需要同步数据库

重启mysql服务

  1. 从服务同步主数据库

stop slave;

change

master to master_host=\’172.27.185.1\’,master_user=\’root\’,master_password=\’root\’;

start slave;

show slave status;

 

MyCat

是一个开源的分布式数据库系统，但是因为数据库一般都有自己的数据库引擎，而Mycat并没有属于自己的独有数据库引擎，所有严格意义上说并不能算是一个完整的数据库系统，只能说是一个在应用和数据库之间起桥梁作用的中间件。

在Mycat中间件出现之前，MySQL主从复制集群，如果要实现读写分离，一般是在程序段实现，这样就带来了一个问题，即数据段和程序的耦合度太高，如果数据库的地址发生了改变，那么我的程序也要进行相应的修改，如果数据库不小心挂掉了，则同时也意味着程序的不可用，而对于很多应用来说，并不能接受；

 
引入Mycat中间件能很好地对程序和数据库进行解耦，这样，程序只需关注数据库中间件的地址，而无需知晓底层数据库是如何提供服务的，大量的通用数据聚合、事务、数据源切换等工作都由中间件来处理；

 
Mycat中间件的原理是对数据进行分片处理，从原有的一个库，被切分为多个分片数据库，所有的分片数据库集群构成完成的数据库存储，有点类似磁盘阵列中的RAID0.

 

Redis 是完全开源免费的，遵守BSD协议，是一个高性能的key-value数据库。

Redis 与其他 key – value 缓存产品有以下三个特点：

Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。

Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。

Redis支持数据的备份，即master-slave模式的数据备份。

   主要能够体现
解决数据库的访问压力。

   例如:短信验证码时间有效期、session共享解决方案。

基于本机内存的缓存

为了解决调用API依然需要2秒的问题，经过排查，其主要原因在于使用SQL获取热点新闻的过程中消耗了将近2秒的时间，于是乎，我们又想到了一个简单粗暴的解决方案，即把SQL查询的结果直接缓存在当前api服务器的内存中（设置缓存有效时间为1分钟）。后续1分钟内的请求直接读缓存，不再花费2秒去执行SQL了。假如这个api每秒接收到的请求时100个，那么一分钟就是6000个，也就是只有前2秒拥挤过来的请求会耗时2秒，后续的58秒中的所有请求都可以做到即使响应，而无需再等2秒的时间。

服务端的Redis

在API服务器的内存都被缓存塞满的时候，我们发现不得不另想解决方案了。最直接的想法就是我们把这些缓存都丢到一个专门的服务器上吧，把它的内存配置的大大的。然后我们就盯上了redis。。。至于如何配置部署redis这里不解释了，redis官方有详细的介绍。随后我们就用上了一台单独的服务器作为Redis的服务器，API服务器的内存压力得以解决。

持久化（Persistence）

单台的Redis服务器一个月总有那么几天心情不好，心情不好就罢工了，导致所有的缓存都丢失了（redis的数据是存储在内存的嘛）。虽然可以把Redis服务器重新上线，但是由于内存的数据丢失，造成了缓存雪崩，API服务器和数据库的压力还是一下子就上来了。所以这个时候Redis的持久化功能就派上用场了，可以缓解一下缓存雪崩带来的影响。redis的持久化指的是redis会把内存的中的数据写入到硬盘中，在redis重新启动的时候加载这些数据，从而最大限度的降低缓存丢失带来的影响。

哨兵（Sentinel）和复制（Replication）

Redis服务器毫无征兆的罢工是个麻烦事。那么怎办办？答曰：备份一台，你挂了它上。那么如何得知某一台redis服务器挂了，如何切换，如何保证备份的机器是原始服务器的完整备份呢？这时候就需要Sentinel和Replication出场了。Sentinel可以管理多个Redis服务器，它提供了监控，提醒以及自动的故障转移的功能；Replication则是负责让一个Redis服务器可以配备多个备份的服务器。Redis也是利用这两个功能来保证Redis的高可用的。此外，Sentinel功能则是对Redis的发布和订阅功能的一个利用。

集群（Cluster）

单台服务器资源的总是有上限的，CPU资源和IO资源我们可以通过主从复制，进行读写分离，把一部分CPU和IO的压力转移到从服务器上。但是内存资源怎么办，主从模式做到的只是相同数据的备份，并不能横向扩充内存；单台机器的内存也只能进行加大处理，但是总有上限的。所以我们就需要一种解决方案，可以让我们横向扩展。最终的目的既是把每台服务器只负责其中的一部分，让这些所有的服务器构成一个整体，对外界的消费者而言，这一组分布式的服务器就像是一个集中式的服务器一样

 

区别：

1、存储方式不同

memecache 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小；redis有部份存在硬盘上，这样能保证数据的持久性，支持数据的持久化（笔者注：有快照和AOF日志两种持久化方式，在实际应用的时候，要特别注意配置文件快照参数，要不就很有可能服务器频繁满载做dump）。 

2、数据支持类型不同

redis在数据支持上要比memecache多的多。 

3、使用底层模型不同

新版本的redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。 

4、运行环境不同 

redis目前官方只支持LINUX 上去行，从而省去了对于其它系统的支持，这样的话可以更好的把精力用于本系统 环境上的优化，虽然后来微软有一个小组为其写了补丁。但是没有放到主干上。

182.redis 为什么是单线程的？

因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。

二、详细原因：

1、不需要各种锁的性能消耗

Redis的数据结构并不全是简单的Key-Value，还有list，hash等复杂的结构，这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在hash当中添加或者删除

一个对象。这些操作可能就需要加非常多的锁，导致的结果是同步开销大大增加。

总之，在单线程的情况下，就不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。

2、单线程多进程集群方案

单线程的威力实际上非常强大，每核心效率也非常高，多线程自然是可以比单线程有更高的性能上限，但是在今天的计算环境中，即使是单机多线程的上限也往往不能满足需要了，需要进一步摸索的是多服务器集群化的方案，这些方案中多线程的技术照样是用不上的。

3、CPU消耗

采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU。

但是如果CPU成为Redis瓶颈，或者不想让服务器其他CUP核闲置，那怎么办？

可以考虑多起几个Redis进程，Redis是key-value数据库，不是关系数据库，数据之间没有约束。只要客户端分清哪些key放在哪个Redis进程上就可以了。

1、单进程单线程优势

代码更清晰，处理逻辑更简单

不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗

不存在多进程或者多线程导致的切换而消耗CPU

2、单进程单线程弊端

无法发挥多核CPU性能，不过可以通过在单机开多个Redis实例来完善；

183.什么是缓存穿透？怎么解决？

1、string（字符串）

2、hash（哈希）

　　Redis hash 是一个键值(key=>value)对集合。
　　Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。

3、list（列表）

　　Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

4、set（集合）

　　Redis的Set是string类型的无序集合。

5、zset(sorted set：有序集合)

　　Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
　　不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。
　　zset的成员是唯一的,但分数(score)却可以重复。

 

Redisson,Jedis，lettuce等等，官方推荐使用Redisson。

186.jedis 和 redisson 有哪些区别？

Jedis是Redis的java实现客户端，其API提供了比较全面的Redis命令的支持；Redisson实现了分布式和可扩展的Java数据结构，和Jedis相比，功能较为简单，不支持字符串操作，不支持排序、事务‘管道、分区等Redis特性。Redisson的宗旨是促进使用者对Redis的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上。

先删除缓存，再更新数据库   先更新数据库，再删缓存

主要有两种方式：
① 快照持久化
在Redis配置文件中已经自动开启了，
格式是：save N M
表示在N秒之内，redis至少发生M次修改则redis抓快照到磁盘。
当然我们也可以手动执行save或者bgsave（异步）命令来做快照
②append only file AOF持久化
总共有三种模式，如
appendfsync everysec默认的是每秒强制写入磁盘一次
appendfsync always 每次执行写操作的时候就强制写入磁盘
appendfsync no 完全取决于os，性能最好但是持久化没法保证
其中第三种模式最好。redis默认的也是采取第三种模式。

189.redis 怎么实现分布式锁？

190.redis 分布式锁有什么缺陷？

一.redisObject对象

二.缩减键值对象

三.共享对象池

四.字符串优化

五.编码优化

六.控制key的数量

 

1）voltile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

2）volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

3）volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

4）allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

5）allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

6）no-enviction（驱逐）：禁止驱逐数据

1.master写内存快照，seve命令调度rdbsave函数，会阻塞主线程的工程，当快照比较大的时候对性能的影响是非常大的，会间断性暂停服务 。所以master最好不要写内存快照。

 

2.master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响master重启时的恢复速度。master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化，如果数据比较关键，某个slave开启AOF备份数据，策略每秒为同步一次。

 

3.master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂的服务暂停现象。

 

  1. redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，slave和master最好在同一个局域网内。

Redis优势

性能极高 –
Redis能读的速度是110000次/s,写的速度是81000次/s 。

丰富的数据类型
– Redis支持二进制案例的 Strings,
Lists, Hashes, Sets 及 Ordered
Sets 数据类型操作。

原子
– Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。

丰富的特性 –
Redis还支持
publish/subscribe, 通知, key 过期等等特性。

 

Redis与其他key-value存储有什么不同？

Redis有着更为复杂的数据结构并且提供对他们的原子性操作，这是一个不同于其他数据库的进化路径。Redis的数据类型都是基于基本数据结构的同时对程序员透明，无需进行额外的抽象。

Redis运行在内存中但是可以持久化到磁盘，所以在对不同数据集进行高速读写时需要权衡内存，因为数据量不能大于硬件内存。在内存数据库方面的另一个优点是，相比在磁盘上相同的复杂的数据结构，在内存中操作起来非常简单，这样Redis可以做很多内部复杂性很强的事情。同时，在磁盘格式方面他们是紧凑的以追加的方式产生的，因为他们并不需要进行随机访问。

 

Redis的基本数据类型

字符串类型(String)

redis 127.0.0.1:6379> SET
mykey “redis”

OK

redis 127.0.0.1:6379> GET
mykey

“redis”

 

在上面的例子中，SET和GET是redis中的命令，而mykey是键的名称。

Redis字符串命令用于管理Redis中的字符串值。以下是使用Redis字符串命令的语法。

  1. redis 127.0.0.1:6379> COMMAND KEY_NAME
  1. Shell

示例

  1. redis 127.0.0.1:6379> SET mykey "redis" 
  1. OK 
  1. redis 127.0.0.1:6379> GET mykey 
  1. "redis"
  1. Shell

在上面的例子中，SET和GET是redis中的命令，而mykey是键的名称。

Redis字符串命令

下表列出了一些用于在Redis中管理字符串的基本命令。

编号

命令

描述说明

1

SET key value

此命令设置指定键的值。

2

GET key

获取指定键的值。

3

GETRANGE key start end

获取存储在键上的字符串的子字符串。

4

GETSET key value

设置键的字符串值并返回其旧值。

5

GETBIT key offset

返回在键处存储的字符串值中偏移处的位值。

6

MGET key1 [key2..]

获取所有给定键的值

7

SETBIT key offset value

存储在键上的字符串值中设置或清除偏移处的位

8

SETEX key seconds value

使用键和到期时间来设置值

9

SETNX key value

设置键的值，仅当键不存在时

10

SETRANGE key offset value

在指定偏移处开始的键处覆盖字符串的一部分

11

STRLEN key

获取存储在键中的值的长度

12

MSET key value [key value …]

为多个键分别设置它们的值

13

MSETNX key value [key value …]

为多个键分别设置它们的值，仅当键不存在时

14

PSETEX key milliseconds value

设置键的值和到期时间(以毫秒为单位)

15

INCR key

将键的整数值增加1

16

INCRBY key increment

将键的整数值按给定的数值增加

17

INCRBYFLOAT key increment

将键的浮点值按给定的数值增加

18

DECR key

将键的整数值减1

19

DECRBY key decrement

按给定数值减少键的整数值

20

APPEND key value

将指定值附加到键

 

列表类型(List)

Redis列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）

一个列表最多可以包含 232 – 1 个元素 (4294967295, 每个列表超过40亿个元素)。

 

  1. redis 127.0.0.1:6379> LPUSH runoobkey redis
  1. (integer) 1
  1. redis 127.0.0.1:6379> LPUSH runoobkey mongodb
  1. (integer) 2
  1. redis 127.0.0.1:6379> LPUSH runoobkey mysql
  1. (integer) 3
  1. redis 127.0.0.1:6379> LRANGE runoobkey 0 10
  1.  
  1. 1) "mysql"
  1. 2) "mongodb"
  1. 3) "redis"

 

Redis 列表命令

下表列出了列表相关的基本命令：

序号

命令及描述

1

BLPOP key1 [key2 ] timeout 
移出并获取列表的第一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。

2

BRPOP
key1 [key2 ] timeout 
移出并获取列表的最后一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。

3

BRPOPLPUSH
source destination timeout 
从列表中弹出一个值，将弹出的元素插入到另外一个列表中并返回它； 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。

4

LINDEX
key index 
通过索引获取列表中的元素

5

LINSERT
key BEFORE|AFTER pivot value 
在列表的元素前或者后插入元素

6

LLEN
key 
获取列表长度

7

LPOP
key 
移出并获取列表的第一个元素

8

LPUSH
key value1 [value2] 
将一个或多个值插入到列表头部

9

LPUSHX
key value 
将一个值插入到已存在的列表头部

10

LRANGE
key start stop 
获取列表指定范围内的元素

11

LREM
key count value 
移除列表元素

12

LSET
key index value 
通过索引设置列表元素的值

13

LTRIM
key start stop 
对一个列表进行修剪(trim)，就是说，让列表只保留指定区间内的元素，不在指定区间之内的元素都将被删除。

14

RPOP
key 
移除并获取列表最后一个元素

15

RPOPLPUSH
source destination 
移除列表的最后一个元素，并将该元素添加到另一个列表并返回

16

RPUSH
key value1 [value2] 
在列表中添加一个或多个值

17

RPUSHX
key value 
为已存在的列表添加值

 

 

集合(Set)

Redis的Set是string类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。

Redis 中 集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

集合中最大的成员数为 232 – 1 (4294967295, 每个集合可存储40多亿个成员)。

 

实例

  1. redis 127.0.0.1:6379> SADD runoobkey redis
  1. (integer) 1
  1. redis 127.0.0.1:6379> SADD runoobkey mongodb
  1. (integer) 1
  1. redis 127.0.0.1:6379> SADD runoobkey mysql
  1. (integer) 1
  1. redis 127.0.0.1:6379> SADD runoobkey mysql
  1. (integer) 0
  1. redis 127.0.0.1:6379> SMEMBERS runoobkey
  1.  
  1. 1) "mysql"
  1. 2) "mongodb"
  1. 3) "redis"

在以上实例中我们通过 SADD 命令向名为 runoobkey 的集合插入的三个元素。

下表列出了 Redis 集合基本命令：

序号

命令及描述

1

SADD key member1 [member2] 
向集合添加一个或多个成员

2

SCARD key 
获取集合的成员数

3

SDIFF key1 [key2] 
返回给定所有集合的差集

4

SDIFFSTORE
destination key1 [key2] 
返回给定所有集合的差集并存储在 destination 中

5

SINTER key1 [key2] 
返回给定所有集合的交集

6

SINTERSTORE
destination key1 [key2] 
返回给定所有集合的交集并存储在 destination 中

7

SISMEMBER
key member 
判断 member 元素是否是集合 key 的成员

8

SMEMBERS key 
返回集合中的所有成员

9

SMOVE source destination
member 
将 member 元素从 source 集合移动到
destination 集合

10

SPOP key 
移除并返回集合中的一个随机元素

11

SRANDMEMBER
key [count] 
返回集合中一个或多个随机数

12

SREM key member1 [member2] 
移除集合中一个或多个成员

13

SUNION key1 [key2] 
返回所有给定集合的并集

14

SUNIONSTORE
destination key1 [key2] 
所有给定集合的并集存储在 destination 集合中

15

SSCAN key cursor [MATCH
pattern] [COUNT count] 
迭代集合中的元素

 

 

有序集合(sorted set)

Redis 有序集合和集合一样也是string类型元素的集合,且不允许重复的成员。

不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

有序集合的成员是唯一的,但分数(score)却可以重复。

集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。 集合中最大的成员数为 232 – 1 (4294967295, 每个集合可存储40多亿个成员)。

实例

  1. redis 127.0.0.1:6379> ZADD runoobkey 1 redis
  1. (integer) 1
  1. redis 127.0.0.1:6379> ZADD runoobkey 2 mongodb
  1. (integer) 1
  1. redis 127.0.0.1:6379> ZADD runoobkey 3 mysql
  1. (integer) 1
  1. redis 127.0.0.1:6379> ZADD runoobkey 3 mysql
  1. (integer) 0
  1. redis 127.0.0.1:6379> ZADD runoobkey 4 mysql
  1. (integer) 0
  1. redis 127.0.0.1:6379> ZRANGE runoobkey 0 10 WITHSCORES
  1.  
  1. 1) "redis"
  1. 2) "1"
  1. 3) "mongodb"
  1. 4) "2"
  1. 5) "mysql"
  1. 6) "4"

在以上实例中我们通过命令 ZADD 向 redis 的有序集合中添加了三个值并关联上分数。

下表列出了 redis 有序集合的基本命令:

序号

命令及描述

1

ZADD key score1 member1 [score2 member2] 
向有序集合添加一个或多个成员，或者更新已存在成员的分数

2

ZCARD
key 
获取有序集合的成员数

3

ZCOUNT
key min max 
计算在有序集合中指定区间分数的成员数

4

ZINCRBY
key increment member 
有序集合中对指定成员的分数加上增量 increment

5

ZINTERSTORE
destination numkeys key [key …] 
计算给定的一个或多个有序集的交集并将结果集存储在新的有序集合 key 中

6

ZLEXCOUNT
key min max 
在有序集合中计算指定字典区间内成员数量

7

ZRANGE
key start stop [WITHSCORES] 
通过索引区间返回有序集合成指定区间内的成员

8

ZRANGEBYLEX
key min max [LIMIT offset count] 
通过字典区间返回有序集合的成员

9

ZRANGEBYSCORE
key min max [WITHSCORES] [LIMIT] 
通过分数返回有序集合指定区间内的成员

10

ZRANK
key member 
返回有序集合中指定成员的索引

11

ZREM
key member [member …] 
移除有序集合中的一个或多个成员

12

ZREMRANGEBYLEX
key min max 
移除有序集合中给定的字典区间的所有成员

13

ZREMRANGEBYRANK
key start stop 
移除有序集合中给定的排名区间的所有成员

14

ZREMRANGEBYSCORE
key min max 
移除有序集合中给定的分数区间的所有成员

15

ZREVRANGE
key start stop [WITHSCORES] 
返回有序集中指定区间内的成员，通过索引，分数从高到底

16

ZREVRANGEBYSCORE
key max min [WITHSCORES] 
返回有序集中指定分数区间内的成员，分数从高到低排序

17

ZREVRANK
key member 
返回有序集合中指定成员的排名，有序集成员按分数值递减(从大到小)排序

18

ZSCORE
key member 
返回有序集中，成员的分数值

19

ZUNIONSTORE
destination numkeys key [key …] 
计算给定的一个或多个有序集的并集，并存储在新的 key 中

20

ZSCAN
key cursor [MATCH pattern] [COUNT count] 
迭代有序集合中的元素（包括元素成员和元素分值）

 

哈希(Hash)

Redis hash 是一个string类型的field和value的映射表，hash特别适合用于存储对象。

Redis 中每个 hash 可以存储 232 – 1 键值对（40多亿）。

实例

  1. 127.0.0.1:6379>  HMSET runoobkey name "redis tutorial" description "redis basic commands for caching" likes 20 visitors 23000
  1. OK
  1. 127.0.0.1:6379>  HGETALL runoobkey
  1. 1) "name"
  1. 2) "redis tutorial"
  1. 3) "description"
  1. 4) "redis basic commands for caching"
  1. 5) "likes"
  1. 6) "20"
  1. 7) "visitors"
  1. 8) "23000"

hset  key  mapHey MapValue

在以上实例中，我们设置了 redis 的一些描述信息(name, description, likes, visitors) 到哈希表的 runoobkey 中。

下表列出了 redis hash 基本的相关命令：

序号

命令及描述

1

HDEL key field2 [field2] 
删除一个或多个哈希表字段

2

HEXISTS
key field 
查看哈希表 key 中，指定的字段是否存在。

3

HGET key field 
获取存储在哈希表中指定字段的值。

4

HGETALL
key 
获取在哈希表中指定 key 的所有字段和值

5

HINCRBY
key field increment 
为哈希表 key 中的指定字段的整数值加上增量 increment 。

6

HINCRBYFLOAT
key field increment 
为哈希表 key 中的指定字段的浮点数值加上增量 increment 。

7

HKEYS key 
获取所有哈希表中的字段

8

HLEN key 
获取哈希表中字段的数量

9

HMGET key field1 [field2] 
获取所有给定字段的值

10

HMSET key field1 value1
[field2 value2 ] 
同时将多个 field-value (域-值)对设置到哈希表 key 中。

11

HSET key field value 
将哈希表 key 中的字段 field 的值设为 value 。

12

HSETNX key field value 
只有在字段 field 不存在时，设置哈希表字段的值。

13

HVALS key 
获取哈希表中所有值

14

HSCAN
key cursor [MATCH pattern] [COUNT count] 
迭代哈希表中的键值对。

 

概述

1、redis的复制功能是支持多个数据库之间的数据同步。一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。

2、通过redis的复制功能可以很好的实现数据库的读写分离，提高服务器的负载能力。主数据库主要进行写操作，而从数据库负责读操作。

主从复制过程

主从复制过程：见下图

 

 

过程：

1：当一个从数据库启动时，会向主数据库发送sync命令，

2：主数据库接收到sync命令后会开始在后台保存快照（执行rdb操作），并将保存期间接收到的命令缓存起来

3：当快照完成后，redis会将快照文件和所有缓存的命令发送给从数据库。

4：从数据库收到后，会载入快照文件并执行收到的缓存的命令。

修改redis.conf

修改从redis中的 redis.conf文件

slaveof 192.168.33.130 6379  

masterauth
123456— 主redis服务器配置了密码,则需要配置

 

Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:

·        监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。

·        提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

·        自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement
protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.

每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).

若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master”彻底死亡”(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.

虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 –sentinel 选项来启动哨兵(sentinel).

哨兵(sentinel) 的一些设计思路和zookeeper非常类似

单个哨兵(sentinel)

 

实现步骤:

1.拷贝到etc目录

cp sentinel.conf  /usr/local/redis/etc

2.修改sentinel.conf配置文件

sentinel monitor mymast  192.168.110.133 6379 1  #主节点 名称 IP 端口号
选举次数

3. 修改心跳检测 5000毫秒

sentinel down-after-milliseconds mymaster
5000

4.sentinel parallel-syncs mymaster 2 — 做多多少合格节点

5. 启动哨兵模式

./redis-server
/usr/local/redis/etc/sentinel.conf –sentinel &

6. 停止哨兵模式

 

Redis 事务可以一次执行多个命令， 并且带有以下两个重要的保证：

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

一个事务从开始到执行会经历以下三个阶段：

开始事务。

命令入队。

执行事务。

以下是一个事务的例子， 它先以 MULTI 开始一个事务， 然后将多个命令入队到事务中， 最后由 EXEC 命令触发事务， 一并执行事务中的所有命令：

  1. redis 127.0.0.1:6379> MULTI
  1. OK
  1.  
  1. redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"
  1. QUEUED
  1.  
  1. redis 127.0.0.1:6379> GET book-name
  1. QUEUED
  1.  
  1. redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series"
  1. QUEUED
  1.  
  1. redis 127.0.0.1:6379> SMEMBERS tag
  1. QUEUED
  1.  
  1. redis 127.0.0.1:6379> EXEC
  1. 1) OK
  1. 2) "Mastering C++ in 21 days"
  1. 3) (integer) 3
  1. 4) 1) "Mastering Series"
  1.    2) "C++"
  1.    3) "Programming"

 

 

 

什么是Redis持久化,就是将内存数据保存到硬盘。

Redis 持久化存储 (AOF 与 RDB 两种模式)

RDB 是在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。
优点：使用单独子进程来进行持久化，主进程不会进行任何
IO 操作，保证了
redis 的高性能
缺点：RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

这里说的这个执行数据写入到临时文件的时间点是可以通过配置来自己确定的，通过配置redis
在 n 秒内如果超过 m 个 key 被修改这执行一次
RDB 操作。这个操作就类似于在这个时间点来保存一次
Redis 的所有数据，一次快照数据。所有这个持久化方法也通常叫做
snapshots。

RDB 默认开启，redis.conf 中的具体配置参数如下；

#dbfilename：持久化数据存储在本地的文件

dbfilename dump.rdb

#dir：持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下

dir ./

##snapshot触发的时机，save   

##如下为900秒后，至少有一个变更操作，才会snapshot 

##对于此值的设置，需要谨慎，评估系统的变更操作密集程度 

##可以通过“save “””来关闭snapshot功能 

#save时间，以下分别表示更改了1个key时间隔900s进行持久化存储；更改了10个key300s进行存储；更改10000个key60s进行存储。

save 900 1

save 300 10

save 60 10000

##当snapshot时出现错误无法继续时，是否阻塞客户端“变更操作”，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等 

stop-writes-on-bgsave-error yes 

##是否启用rdb文件压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的网络传输时间 

rdbcompression yes 

 

Append-only
file，将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部，在 append 操作返回后(已经写入到文件或者即将写入)，才进行实际的数据变更，“日志文件”保存了历史所有的操作过程；当 server 需要数据恢复时，可以直接 replay 此日志文件，即可还原所有的操作过程。AOF 相对可靠，它和 mysql 中 bin.log、apache.log、zookeeper 中 txn-log 简直异曲同工。AOF 文件内容是字符串，非常容易阅读和解析。
优点：可以保持更高的数据完整性，如果设置追加 file 的时间是 1s，如果
redis 发生故障，最多会丢失 1s 的数据；且如果日志写入不完整支持 redis-check-aof 来进行日志修复；AOF 文件没被 rewrite 之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的
flushall）。
缺点：AOF 文件比 RDB 文件大，且恢复速度慢。

我们可以简单的认为
AOF 就是日志文件，此文件只会记录“变更操作”(例如：set/del
等)，如果
server 中持续的大量变更操作，将会导致
AOF 文件非常的庞大，意味着 server 失效后，数据恢复的过程将会很长；事实上，一条数据经过多次变更，将会产生多条
AOF 记录，其实只要保存当前的状态，历史的操作记录是可以抛弃的；因为
AOF 持久化模式还伴生了“AOF
rewrite”。
AOF 的特性决定了它相对比较安全，如果你期望数据更少的丢失，那么可以采用
AOF 模式。如果 AOF 文件正在被写入时突然 server 失效，有可能导致文件的最后一次记录是不完整，你可以通过手工或者程序的方式去检测并修正不完整的记录，以便通过
aof 文件恢复能够正常；同时需要提醒，如果你的
redis 持久化手段中有 aof，那么在 server 故障失效后再次启动前，需要检测 aof 文件的完整性。

AOF 默认关闭，开启方法，修改配置文件 reds.conf：appendonly yes

##此选项为aof功能的开关，默认为“no”，可以通过“yes”来开启aof功能 

##只有在“yes”下，aof重写/文件同步等特性才会生效 

appendonly yes 

 

##指定aof文件名称 

appendfilename
appendonly.aof 

 

##指定aof操作中文件同步策略，有三个合法值：always everysec no,默认为everysec 

appendfsync everysec 

##在aof-rewrite期间，appendfsync是否暂缓文件同步，“no”表示“不暂缓”，“yes”表示“暂缓”，默认为“no” 

no-appendfsync-on-rewrite
no 

 

##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb” 

auto-aof-rewrite-min-size
64mb 

 

##相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。 

##每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1
+ p)之后 

##触发下一次rewrite，每一次aof记录的添加，都会检测当前aof文件的尺寸。 

auto-aof-rewrite-percentage 100 

 

 

AOF 是文件操作，对于变更操作比较密集的 server，那么必将造成磁盘 IO 的负荷加重；此外 linux 对文件操作采取了“延迟写入”手段，即并非每次 write 操作都会触发实际磁盘操作，而是进入了 buffer 中，当 buffer 数据达到阀值时触发实际写入(也有其他时机)，这是
linux 对文件系统的优化，但是这却有可能带来隐患，如果
buffer 没有刷新到磁盘，此时物理机器失效(比如断电)，那么有可能导致最后一条或者多条
aof 记录的丢失。通过上述配置文件，可以得知
redis 提供了 3 中 aof 记录同步选项：

always：每一条 aof 记录都立即同步到文件，这是最安全的方式，也以为更多的磁盘操作和阻塞延迟，是
IO 开支较大。

everysec：每秒同步一次，性能和安全都比较中庸的方式，也是 redis 推荐的方式。如果遇到物理服务器故障，有可能导致最近一秒内 aof 记录丢失(可能为部分丢失)。

no：redis 并不直接调用文件同步，而是交给操作系统来处理，操作系统可以根据 buffer 填充情况 / 通道空闲时间等择机触发同步；这是一种普通的文件操作方式。性能较好，在物理服务器故障时，数据丢失量会因
OS 配置有关。

其实，我们可以选择的太少，everysec
是最佳的选择。如果你非常在意每个数据都极其可靠，建议你选择一款“关系性数据库”吧。
AOF 文件会不断增大，它的大小直接影响“故障恢复”的时间,
而且 AOF 文件中历史操作是可以丢弃的。AOF rewrite 操作就是“压缩”AOF
文件的过程，当然 redis 并没有采用“基于原
aof 文件”来重写的方式，而是采取了类似 snapshot 的方式：基于 copy-on-write，全量遍历内存中数据，然后逐个序列到 aof 文件中。因此 AOF rewrite 能够正确反应当前内存数据的状态，这正是我们所需要的；*rewrite 过程中，对于新的变更操作将仍然被写入到原 AOF 文件中，同时这些新的变更操作也会被 redis 收集起来(buffer，copy-on-write 方式下，最极端的可能是所有的 key 都在此期间被修改，将会耗费 2 倍内存)，当内存数据被全部写入到新的
aof 文件之后，收集的新的变更操作也将会一并追加到新的
aof 文件中，此后将会重命名新的
aof 文件为
appendonly.aof, 此后所有的操作都将被写入新的
aof 文件。如果在 rewrite 过程中，出现故障，将不会影响原 AOF 文件的正常工作，只有当 rewrite 完成之后才会切换文件，因为 rewrite 过程是比较可靠的。*

触发
rewrite 的时机可以通过配置文件来声明，同时
redis 中可以通过
bgrewriteaof 指令人工干预。

redis-cli
-h ip -p port bgrewriteaof

因为
rewrite 操作 /aof 记录同步 /snapshot 都消耗磁盘 IO，redis
采取了“schedule”策略：无论是“人工干预”还是系统触发，snapshot 和 rewrite 需要逐个被执行。

AOF
rewrite 过程并不阻塞客户端请求。系统会开启一个子进程来完成。

 

OF 和 RDB 各有优缺点，这是有它们各自的特点所决定：

1) AOF 更加安全，可以将数据更加及时的同步到文件中，但是 AOF 需要较多的磁盘 IO 开支，AOF 文件尺寸较大，文件内容恢复数度相对较慢。
*2) snapshot，安全性较差，它是“正常时期”数据备份以及
master-slave 数据同步的最佳手段，文件尺寸较小，恢复数度较快。

可以通过配置文件来指定它们中的一种，或者同时使用它们(不建议同时使用)，或者全部禁用，在架构良好的环境中，master
通常使用 AOF，slave 使用 snapshot，主要原因是 master 需要首先确保数据完整性，它作为数据备份的第一选择；slave 提供只读服务(目前
slave 只能提供读取服务)，它的主要目的就是快速响应客户端 read 请求；但是如果你的 redis 运行在网络稳定性差 / 物理环境糟糕情况下，建议你
master 和 slave 均采取 AOF，这个在 master 和 slave 角色切换时，可以减少“人工数据备份”/“人工引导数据恢复”的时间成本；如果你的环境一切非常良好，且服务需要接收密集性的 write 操作，那么建议 master 采取 snapshot，而 slave 采用 AOF。

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

Redis 客户端可以订阅任意数量的频道。

下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：

 

当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：

 

 

以下实例演示了发布订阅是如何工作的。在我们实例中我们创建了订阅频道名为 redisChat:

  1. redis 127.0.0.1:6379> SUBSCRIBE redisChat
  1.  
  1. Reading messages... (press Ctrl-C to quit)
  1. 1) "subscribe"
  1. 2) "redisChat"
  1. 3) (integer) 1

现在，我们先重新开启个 redis 客户端，然后在同一个频道 redisChat 发布两次消息，订阅者就能接收到消息。

  1. redis 127.0.0.1:6379> PUBLISH redisChat "Redis is a great caching technique"
  1.  
  1. (integer) 1
  1.  
  1. redis 127.0.0.1:6379> PUBLISH redisChat "Learn redis by runoob.com"
  1.  
  1. (integer) 1
  1.  
  1. # 订阅者的客户端会显示如下消息
  1. 1) "message"
  1. 2) "redisChat"
  1. 3) "Redis is a great caching technique"
  1. 1) "message"
  1. 2) "redisChat"
  1. 3) "Learn redis by runoob.com"

Redis 发布订阅命令

下表列出了 redis 发布订阅常用命令：

序号

命令及描述

1

PSUBSCRIBE pattern [pattern …] 
订阅一个或多个符合给定模式的频道。

2

PUBSUB
subcommand [argument [argument …]] 
查看订阅与发布系统状态。

3

PUBLISH
channel message 
将信息发送到指定的频道。

4

PUNSUBSCRIBE
[pattern [pattern …]] 
退订所有给定模式的频道。

5

SUBSCRIBE
channel [channel …] 
订阅给定的一个或多个频道的信息。

6

UNSUBSCRIBE
[channel [channel …]] 
指退订给定的频道。

 

nginx是一款高性能的http 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器。由俄罗斯的程序设计师Igor Sysoev所开发，官方测试nginx能够支支撑5万并发链接，并且cpu、内存等资源消耗却非常低，运行非常稳定，所以现在很多知名的公司都在使用nginx。

1、http服务器。Nginx是一个http服务可以独立提供http服务。可以做网页静态服务器。

2、虚拟主机。可以实现在一台服务器虚拟出多个网站。例如个人网站使用的虚拟主机。

3、反向代理，负载均衡。当网站的访问量达到一定程度后，单台服务器不能满足用户的请求时，需要用多台服务器集群可以使用nginx做反向代理。并且多台服务器可以平均分担负载，不会因为某台服务器负载高宕机而某台服务器闲置的情况。

 

 

占内存小，可以实现高并发连接、处理响应快。

可以实现http服务器、虚拟主机、反向代理、负载均衡。

nginx配置简单

可以不暴露真实服务器IP地址

 

 nginx.conf文件的结构

nginx的配置由特定的标识符(指令符)分为多个不同的模块。 
指令符分为简单指令和块指令。

  • 简单指令格式：[name parameters;]
  • 块指令格式：和简单指令格式有一样的结构，但其结束标识符不是分号，而是大括号{},块指令内部可以包含simple directives 和block directives, 可以称块指令为上下文(e.g.
    events, http, server, location)

conf文件中，所有不属于块指令的简单指令都属于main上下文的，http块指令属于main上下文，server块指令http上下文。

配置静态访问

Web server很重要一部分工作就是提供静态页面的访问，例如images, html page。nginx可以通过不同的配置，根据request请求，从本地的目录提供不同的文件返回给客户端。 
打开安装目录下的nginx.conf文件，默认配置文件已经在http指令块中创建了一个空的server块，在nginx-1.8.0中的http块中已经创建了一个默认的server块。内容如下：

server {

       
listen       80;

       
server_name  localhost;

       
location / {

            root   html;

            index  index.html index.htm;

       
}

       
error_page   500502503504 
/50x.html;

       
location = /50x.html {

            root   html;

       
}

} 

 

nginx实现反向代理

反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

 

启动一个Tomcat 127.0.0.1:8080

使用nginx反向代理 8080.itmayiedu.com 直接跳转到127.0.0.1:8080

 

Host文件新增

127.0.0.1 8080.itmayiedu.com

127.0.0.1 b8081.itmayiedu.com

nginx.conf 配置

 

配置信息:

    server {

        listen       80;

        server_name  8080.itmayiedu.com;

        location / {

            proxy_pass  http://127.0.0.1:8080;

            index  index.html index.htm;

        }

    }

     server {

        listen       80;

        server_name  b8081.itmayiedu.com;

        location / {

            proxy_pass  http://127.0.0.1:8081;

            index  index.html index.htm;

        }

    }

 

 

nginx实现负载均衡

负载均衡 建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

    负载均衡，英文名称为Load
Balance，其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

 

 

负载均衡策略

1、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。 
upstream backserver
{ 
server 192.168.0.14; 
server 192.168.0.15; 
} 

2、指定权重
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 
upstream backserver
{ 
server 192.168.0.14
weight=10; 
server 192.168.0.15
weight=10; 
} 

3、IP绑定 ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。 
upstream backserver
{ 
ip_hash; 
server
192.168.0.14:88; 
server
192.168.0.15:80; 
} 

配置代码

upstream backserver {

     server 127.0.0.1:8080;

     server 127.0.0.1:8081;

    }

 

    server {

        listen       80;

        server_name  www.itmayiedu.com;

        location / {

                  proxy_pass  http://backserver;

                     index  index.html index.htm;

        }

    }

 

宕机轮训配置规则

 

    server {

        listen       80;

        server_name  www.itmayiedu.com;

        location / {

                  proxy_pass  http://backserver;

                     index  index.html index.htm;

                     proxy_connect_timeout
1;

            proxy_send_timeout 1;

            proxy_read_timeout 1;

        }

             

              }

 

LVS、Ngnix、Tengine（taobao 开发的 Nginx 升级版）、HAProxy（高可用、负载均衡）、Keepalived（故障转移，备机，linux 环境下的组件）

 

 

配置:

server {

        listen       80;

        server_name  www.itmayiedu.com;

        location /A {

                  proxy_pass  http://a.a.com:81/A;

                     index  index.html index.htm;

        }

              location /B {

                  proxy_pass  http://b.b.com:81/B;

                     index  index.html index.htm;

        }

    }

 

location ~ .*\.(jpg|jpeg|JPG|png|gif|icon)$ {

        valid_referers blocked
http://www.itmayiedu.com www.itmayiedu.com;

        if ($invalid_referer) {

            return 403;

        }

              }

 

 

限制请求速度

设置Nginx、Nginx Plus的连接请求在一个真实用户请求的合理范围内。比如，如果你觉得一个正常用户每两秒可以请求一次登录页面，你就可以设置Nginx每两秒钟接收一个客户端IP的请求（大约等同于每分钟30个请求）。

limit_req_zone $binary_remote_addr
zone=one:10m rate=30r/m;

server {

…

location /login.html {

limit_req zone=one;

…

}

}

 

 

`limit_req_zone`命令设置了一个叫one的共享内存区来存储请求状态的特定键值，在上面的例子中是客户端IP($binary_remote_addr)。location块中的`limit_req`通过引用one共享内存区来实现限制访问/login.html的目的。

 

 

设置Nginx、Nginx Plus的连接数在一个真实用户请求的合理范围内。比如，你可以设置每个客户端IP连接/store不可以超过10个。

 

Keepalived是一个免费开源的，用C编写的类似于layer3,
4 & 7交换机制软件，具备我们平时说的第3层、第4层和第7层交换机的功能。主要提供loadbalancing（负载均衡）和 high-availability（高可用）功能，负载均衡实现需要依赖Linux的虚拟服务内核模块（ipvs），而高可用是通过VRRP协议实现多台机器之间的故障转移服务。 

 
上图是Keepalived的功能体系结构，大致分两层：用户空间（user
space）和内核空间（kernel space）。 
内核空间：主要包括IPVS（IP虚拟服务器，用于实现网络服务的负载均衡）和NETLINK（提供高级路由及其他相关的网络功能）两个部份。 
用户空间：

  • WatchDog：负载监控checkers和VRRP进程的状况
  • VRRP Stack：负载负载均衡器之间的失败切换FailOver，如果只用一个负载均稀器，则VRRP不是必须的。
  • Checkers：负责真实服务器的健康检查healthchecking，是keepalived最主要的功能。换言之，可以没有VRRP Stack，但健康检查healthchecking是一定要有的。
  • IPVS wrapper：用户发送设定的规则到内核ipvs代码
  • Netlink Reflector：用来设定vrrp的vip地址等。

Keepalived的所有功能是配置keepalived.conf文件来实现的。

用Nginx 做的负载均衡可以添加ip_hash这个配置，

用haproxy做的负载均衡可以用 balance source这个配置。

从而使同一个ip的请求发到同一台服务器。

利用数据库同步session

利用cookie同步session数据原理图如下

 

缺点:安全性差、http请求都需要带参数增加了带宽消耗

使用spring-session框架，底层实现原理是重写httpsession

引入maven依赖

      <!–spring
boot 与redis应用基本环境配置 –>

        <dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter-redis</artifactId>

        </dependency>

        <!–spring
session 与redis应用基本环境配置,需要开启redis后才可以使用，不然启动Spring boot会报错 –>

        <dependency>

            <groupId>org.springframework.session</groupId>

            <artifactId>spring-session-data-redis</artifactId>

       
</dependency>

 

创建SessionConfig

import
org.springframework.beans.factory.annotation.Value;

import org.springframework.context.annotation.Bean;

import
org.springframework.data.redis.connection.jedis.JedisConnectionFactory;

import
org.springframework.session.data.redis.config.annotation.web.http.EnableRedisHttpSession;

 

//这个类用配置redis服务器的连接

//maxInactiveIntervalInSeconds为SpringSession的过期时间（单位：秒）

@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 1800)

publicclass
SessionConfig {

 

      // 冒号后的值为没有配置文件时，制动装载的默认值

      @Value(“${redis.hostname:localhost}”)

      String
HostName;

      @Value(“${redis.port:6379}”)

      intPort;

 

      @Bean

      public JedisConnectionFactory connectionFactory() {

            JedisConnectionFactory
connection = new JedisConnectionFactory();

            connection.setPort(Port);

            connection.setHostName(HostName);

            returnconnection;

      }

}

 

 

初始化Session

//初始化Session配置

publicclass
SessionInitializer extends
AbstractHttpSessionApplicationInitializer{

   
public SessionInitializer() {

        super(SessionConfig.class);

   
}

}

 

 

控制器层代码

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;

 

import org.springframework.beans.factory.annotation.Value;

import org.springframework.boot.SpringApplication;

import org.springframework.web.bind.annotation.RequestMapping;

import org.springframework.web.bind.annotation.RestController;

 

@RestController

public class SessionController {

 

       @Value(“${server.port}”)

       private String PORT;

 

       public static void
main(String[] args) {

              SpringApplication.run(SessionController.class,
args);

       }

 

       @RequestMapping(“/index”)

       public String index() {

              return
“index:” + PORT;

       }

 

       /**

        *

        * @methodDesc: 功能描述:(往session存放值)

        * @author: 余胜军

        * @param: @param

        *            
httpSession

        * @param: @param

        *     
       sessionKey

        * @param: @param

        *            
sessionValue

        * @param: @return

        * @createTime:2017年10月8日 下午3:55:26

        * @returnType:@param httpSession

        * @returnType:@param sessionKey

        * @returnType:@param sessionValue

        * @returnType:@return String

        * @copyright:上海每特教育科技有限公司

        * @QQ:644064779

        */

       @RequestMapping(“/setSession”)

       public String
setSession(HttpServletRequest request, String sessionKey, String
sessionValue) {

              HttpSession session =
request.getSession(true);

              session.setAttribute(sessionKey,
sessionValue);

              return
“success,port:” + PORT;

       }

 

       /**

        *

        * @methodDesc: 功能描述:(从Session获取值)

        * @author: 余胜军

        * @param: @param

        *            
httpSession

        * @param: @param

        *            
sessionKey

        * @param: @return

        * @createTime:2017年10月8日 下午3:55:47

        * @returnType:@param httpSession

        * @returnType:@param sessionKey

        * @returnType:@return String

        * @copyright:上海每特教育科技有限公司

        * @QQ:644064779

        */

       @RequestMapping(“/getSession”)

       public String getSession(HttpServletRequest
request, String sessionKey) {

              HttpSession session
=null;

              try {

               session = request.getSession(false);

              } catch (Exception e)
{

                e.printStackTrace();

              }

              String value=null;

              if(session!=null){

                     value =
(String) session.getAttribute(sessionKey);

              }

              return
“sessionValue:” + value + “,port:” + PORT;

       }

 

}

 

业务数据库  -》 数据水平分割(分区分表分库)、读写分离、SQL优化

业务应用 -》 逻辑代码优化(算法优化)、公共数据缓存

应用服务器 -》 反向静态代理、配置优化、负载均衡(apache分发，多tomcat实例)

系统环境 -》 JVM调优

页面优化 -》 减少页面连接数、页面尺寸瘦身

1、动态资源和静态资源分离；

2、CDN；

3、负载均衡；

4、分布式缓存；

5、数据库读写分离或数据切分（垂直或水平）；

6、服务分布式部署。

 

 

 

消息中间件

在客户端与服务器进行通讯时.客户端调用后，必须等待服务对象完成处理返回结果才能继续执行。

 客户与服务器对象的生命周期紧密耦合,客户进程和服务对象进程都都必须正常运行;如果由于服务对象崩溃或者网络故障导致用户的请求不可达,客户会受到异常

点对点通信: 客户的一次调用只发送给某个单独的目标对象。

(画图演示)

 

面向消息的中间件(MessageOrlented MiddlewareMOM)较好的解决了以上问
题。发送者将消息发送给消息服务器，消息服务器将消感存放在若千队列中，在合适
的时候再将消息转发给接收者。

这种模式下，发送和接收是异步的，发送者无需等
待; 二者的生命周期未必相同: 发送消息的时候接收者不一定运行，接收消息的时候
发送者也不一定运行;一对多通信: 对于一个消息可以有多个接收者。

JMS介绍

JMS是java的消息服务，JMS的客户端之间可以通过JMS服务进行异步的消息传输。

○
Point-to-Point(P2P) — 点对点

○ Publish/Subscribe(Pub/Sub)—  发布订阅

即点对点和发布订阅模型

 

P2P (点对点)

P2P

  1. P2P模式图 
  2. 涉及到的概念 
    1. 消息队列（Queue）
    2. 发送者(Sender)
    3. 接收者(Receiver)
    4. 每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。
  3. P2P的特点
    1. 每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)
    2. 发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列
    3. 接收者在成功接收消息之后需向队列应答成功

如果你希望发送的每个消息都应该被成功处理的话，那么你需要P2P模式。

应用场景

A用户与B用户发送消息

 

 

Pub/Sub模式图 

涉及到的概念 

主题（Topic）

发布者（Publisher）

订阅者（Subscriber） 
客户端将消息发送到主题。多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。

Pub/Sub的特点

每个消息可以有多个消费者

发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息，而且为了消费消息，订阅者必须保持运行的状态。

为了缓和这样严格的时间相关性，JMS允许订阅者创建一个可持久化的订阅。这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。

如果你希望发送的消息可以不被做任何处理、或者被一个消息者处理、或者可以被多个消费者处理的话，那么可以采用Pub/Sub模型

消息的消费 
在JMS中，消息的产生和消息是异步的。对于消费来说，JMS的消息者可以通过两种方式来消费消息。 
○ 同步 
订阅者或接收者调用receive方法来接收消息，receive方法在能够接收到消息之前（或超时之前）将一直阻塞 
○ 异步 
订阅者或接收者可以注册为一个消息监听器。当消息到达之后，系统自动调用监听器的onMessage方法。

  应用场景:

   用户注册、订单修改库存、日志存储

   画图演示

 

 

 

 

RabbitMQ

是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP,
SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load
balance)或者数据持久化都有很好的支持。

Redis

是一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

 

入队

出队

 

128B

512B

1K

10K

128B

512B

1K

10K

Redis

16088

15961

17094

25

15955

20449

18098

9355

RabbitMQ

10627

9916

9370

2366

3219

3174

2982

1588

ZeroMQ

号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。

ActiveMQ

是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。

Jafka/Kafka

Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理，这一点也是本课题所研究系统所看重的。Apache
Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。

其他一些队列列表HornetQ、Apache
Qpid、Sparrow、Starling、Kestrel、Beanstalkd、Amazon
SQS就不再一一分析。

 

  1. 发送端MQ-client 将消息发送给服务端MQ-server
  2. 服务端MQ-server将消息落地
  3. 服务端MQ-server 回ACK(表示确认) 2.如果3丢失
    发送端在超时后，又会发送一遍，此时重发是MQ-client发起的，消息处理的是MQ-server 为了避免2 重复落地，对每条MQ消息系统内部需要生成一个inner-msg-id,作为去重和幂等的依据，这个内部消息ID 的特点是

在分布式环境中，MQ通讯产生网络延迟，重试补偿中，会造成MQ重复消费。

解决办法:

①   
使用日志+msg-id保存报文信息，作为去重和幂等的依据。

②   
消费端代码抛出异常，不需要重试补偿，使用日志记录报文，下次发版本解决。

Stomp、XMPP

Stomp协议，英文全名Streaming Text Orientated Message
Protocol，中文名称为 ‘流文本定向消息协议’。是一种以纯文本为载体的协议（以文本为载体的意思是它的消息格式规范中没有类似XMPP协议那样的xml格式要求，你可以将它看作‘半结构化数据’）。目前Stomp协议有两个版本：V1.1和V1.2。

一个标准的Stomp协议包括以下部分：命令/信息关键字、头信息、文本内容。如下图所示：

 

以下为一段简单的协议信息示例：

  1. CONNECT
  1. accept-version:1.2
  1. someparam1:value1
  1. someparam2:value2

上面的示例中，我们使用了Stomp协议的CONNECT命令，它的意思为连接到Stomp代理端，并且携带了要求代理端的版本信息和两个自定义的K-V信息（请注意’^@’符号，STOMP协议中用它来表示NULL）。

XMPP基于XML，用于IM系统的开发。国内比较流行的XMPP服务器叫做Openfire，它使用MINA作为下层的网络IO框架（不是MINA2是MINA1）；国外用的比较多的XMPP服务器叫做Tigase，它的官网号称单节点可以支撑50万用户在线，集群可以支持100万用户在线：（http://projects.tigase.org/）

答：

  • 类加载器（ClassLoader）
  • 运行时数据区（Runtime Data Area）
  • 执行引擎（Execution Engine）
  • 本地库接口（Native Interface）

组件的作用： 首先通过类加载器（ClassLoader）会把 Java 代码转换成字节码，运行时数据区（Runtime Data Area）再把字节码加载到内存中，而字节码文件只是 JVM 的一套指令集规范，并不能直接交个底层操作系统去执行，因此需要特定的命令解析器执行引擎（Execution Engine），将字节码翻译成底层系统指令，再交由 CPU 去执行，而这个过程中需要调用其他语言的本地库接口（Native Interface）来实现整个程序的功能

不同虚拟机的运行时数据区可能略微有所不同，但都会遵从 Java 虚拟机规范， Java 虚拟机规范规定的区域分为以下 5 个部分：

  • 程序计数器（Program Counter Register）：当前线程所执行的字节码的行号指示器，字节码解析器的工作是通过改变这个计数器的值，来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能，都需要依赖这个计数器来完成
  • Java 虚拟机栈（Java Virtual Machine Stacks）：用于存储局部变量表、操作数栈、动态链接、方法出口等信息
  • 本地方法栈（Native Method Stack）：与虚拟机栈的作用是一样的，只不过虚拟机栈是服务 Java 方法的，而本地方法栈是为虚拟机调用 Native 方法服务的
  • Java 堆（Java Heap）：Java 虚拟机中内存最大的一块，是被所有线程共享的，几乎所有的对象实例都在这里分配内存
  • 方法区（Methed Area）：用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据
  • 功能方面：堆是用来存放对象的，栈是用来执行程序的
  • 共享性：堆是线程共享的，栈是线程私有的
  • 空间大小：堆大小远远大于栈
  • 队列和栈都是被用来预存储数据的。
  • 队列允许先进先出检索元素，但也有例外的情况，Deque 接口允许从两端检索元素。
  • 栈和队列很相似，但它运行对元素进行后进先出进行检索

在介绍双亲委派模型之前先说下类加载器。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立在 JVM 中的唯一性，每一个类加载器，都有一个独立的类名称空间。类加载器就是根据指定全限定名称将 class 文件加载到 JVM 内存，然后再转化为 class 对象。

类加载器分类：

  • 启动类加载器（Bootstrap ClassLoader），是虚拟机自身的一部分，用来加载Java_HOME/lib/目录中的，或者被 -Xbootclasspath 参数所指定的路径中并且被虚拟机识别的类库
  • 其他类加载器：
  • 扩展类加载器（Extension ClassLoader）：负责加载\lib\ext目录或Java. ext. dirs系统变量指定的路径中的所有类库
  • 应用程序类加载器（Application ClassLoader）。负责加载用户类路径（classpath）上的指定类库，我们可以直接使用这个类加载器。一般情况，如果我们没有自定义类加载器默认就是用这个加载器

双亲委派模型：如果一个类加载器收到了类加载的请求，它首先不会自己去加载这个类，而是把这个请求委派给父类加载器去完成，每一层的类加载器都是如此，这样所有的加载请求都会被传送到顶层的启动类加载器中，只有当父加载无法完成加载请求（它的搜索范围中没找到所需的类）时，子加载器才会尝试去加载类

类装载分为以下 5 个步骤：

  • 加载：根据查找路径找到相应的 class 文件然后导入
  • 检查：检查加载的 class 文件的正确性
  • 准备：给类中的静态变量分配内存空间
  • 解析：虚拟机将常量池中的符号引用替换成直接引用的过程。符号引用就理解为一个标示，而在直接引用直接指向内存中的地址
  • 初始化：对静态变量和静态代码块执行初始化工作

一般有两种方法来判断：

  • 引用计数器：为每个对象创建一个引用计数，有对象引用时计数器 +1，引用被释放时计数 -1，当计数器为 0 时就可以被回收。它有一个缺点不能解决循环引用的问题
  • 可达性分析：从 GC Roots 开始向下搜索，搜索所走过的路径称为引用链。当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是可以被回收的
  • 强引用：发生 gc 的时候不会被回收
  • 软引用：有用但不是必须的对象，在发生内存溢出之前会被回收
  • 弱引用：有用但不是必须的对象，在下一次GC时会被回收
  • 虚引用（幽灵引用/幻影引用）：无法通过虚引用获得对象，用 PhantomReference 实现虚引用，虚引用的用途是在 gc 时返回一个通知
  • 标记-清除算法：标记无用对象，然后进行清除回收。缺点：效率不高，无法清除垃圾碎片
  • 标记-整理算法：标记无用对象，让所有存活的对象都向一端移动，然后直接清除掉端边界以外的内存
  • 复制算法：按照容量划分二个大小相等的内存区域，当一块用完的时候将活着的对象复制到另一块上，然后再把已使用的内存空间一次清理掉。缺点：内存使用率不高，只有原来的一半
  • 分代算法：根据对象存活周期的不同将内存划分为几块，一般是新生代和老年代，新生代基本采用复制算法，老年代采用标记整理算法
  • Serial：最早的单线程串行垃圾回收器
  • Serial Old：Serial 垃圾回收器的老年版本，同样也是单线程的，可以作为 CMS 垃圾回收器的备选预案
  • ParNew：是 Serial 的多线程版本
  • Parallel 和 ParNew 收集器类似是多线程的，但 Parallel 是吞吐量优先的收集器，可以牺牲等待时间换取系统的吞吐量
  • Parallel Old 是 Parallel 老生代版本，Parallel 使用的是复制的内存回收算法，Parallel Old 使用的是标记-整理的内存回收算法
  • CMS：一种以获得最短停顿时间为目标的收集器，非常适用 B/S 系统
  • G1：一种兼顾吞吐量和停顿时间的 GC 实现，是 JDK 9 以后的默认 GC 选项

CMS 是英文 Concurrent Mark-Sweep 的简称，是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上，这种垃圾回收器非常适合。在启动 JVM 的参数加上“-XX:+UseConcMarkSweepGC”来指定使用 CMS 垃圾回收器

CMS 使用的是标记-清除的算法实现的，所以在 gc 的时候回产生大量的内存碎片，当剩余内存不能满足程序运行要求时，系统将会出现 Concurrent Mode Failure，临时 CMS 会采用 Serial Old 回收器进行垃圾清除，此时的性能将会被降低

  • 新生代回收器：Serial、ParNew、Parallel Scavenge
  • 老年代回收器：Serial Old、Parallel Old、CMS
  • 整堆回收器：G1

新生代垃圾回收器一般采用的是复制算法，复制算法的优点是效率高，缺点是内存利用率低；老年代回收器一般采用的是标记-整理的算法进行垃圾回收

　　分代回收器有两个分区：老生代和新生代，新生代默认的空间占比总空间的 1/3，老生代的默认占比是 2/3

新生代使用的是复制算法，新生代里有 3 个分区：Eden、To Survivor、From Survivor，它们的默认占比是 8:1:1，它的执行流程如下：

  • 把 Eden + From Survivor 存活的对象放入 To Survivor 区
  • 清空 Eden 和 From Survivor 分区
  • From Survivor 和 To Survivor 分区交换，From Survivor 变 To Survivor，To Survivor 变 From Survivor

　　每次在 From Survivor 到 To Survivor 移动时都存活的对象，年龄就 +1，当年龄到达 15（默认配置是 15）时，升级为老生代。大对象也会直接进入老生代。 老生代当空间占用到达某个值之后就会触发全局垃圾收回，一般使用标记整理的执行算法。以上这些循环往复就构成了整个分代垃圾回收的整体执行流程

　　JDK 自带了很多监控工具，都位于 JDK 的 bin 目录下，其中最常用的是 jconsole 和 jvisualvm 这两款视图监控工具

  • jconsole：用于对 JVM 中的内存、线程和类等进行监控；
  • jvisualvm：JDK 自带的全能分析工具，可以分析：内存快照、线程快照、程序死锁、监控内存的变化、gc 变化等
  • -Xms2g：初始化推大小为 2g
  • -Xmx2g：堆最大内存为 2g
  • -XX:NewRatio=4：设置年轻的和老年代的内存比例为 1:4
  • -XX:SurvivorRatio=8：设置新生代 Eden 和 Survivor 比例为 8:2
  • –XX:+UseParNewGC：指定使用 ParNew + Serial Old 垃圾回收器组合
  • -XX:+UseParallelOldGC：指定使用 ParNew + ParNew Old 垃圾回收器组合
  • -XX:+UseConcMarkSweepGC：指定使用 CMS + Serial Old 垃圾回收器组合
  • -XX:+PrintGC：开启打印 gc 信息
  • -XX:+PrintGCDetails：打印 gc 详细信息
  • 设置最大堆内存大小   新生代比例配置     老年代参数配置

 

①使用zookeeper实现分布式锁 缺点(需要创建临时节点、和事件通知不易于扩展)

②使用配置文件做一个开关  缺点发布后，需要重启

③数据库唯一约束，缺点效率低

④使用分布式任务调度平台

  XXLJOB

 

所谓虚拟机，就是一台虚拟的机器。他是一款软件，用来执行一系列虚拟计算指令，大体上虚拟机可以分为

系统虚拟机和程序虚拟机， 大名鼎鼎的Visual Box、Vmare就属于系统虚拟机，他们完全是对物理计算的仿真，

提供了一个可以运行完整操作系统的软件平台。

 程序虚拟机典型代码就是Java虚拟机，它专门为执行单个计算程序而计算，在Java虚拟机中执行的指令我们成为Java

自己码指令。无论是系统虚拟机还是程序虚拟机，在上面运行的软件都被限制于虚拟机提供的资源中。

 Java发展至今，出现过很多虚拟机，做初Sun使用的一款叫ClassIc的Java虚拟机，到现在引用最广泛的是HotSpot虚拟

机，除了Sum意外，还有BEA的Jrockit，目前Jrockit和HostSopt都被oralce收入旗下，大有整合的趋势。

 

 

 

1、 类加载子系统:负责从文件系统或者网络加载Class信息，加载的信息存放在一块称之方法区的内存空间。

2、 方法区:就是存放类的信息、常量信息、常量池信息、包括字符串字面量和数字常量等。

3、 Java堆：在Java虚拟机启动的时候建立Java堆，它是Java程序最主要的内存工作区域，几乎所有的对象实例都存放到

Java堆中，堆空间是所有线程共享。

4、 直接内存：JavaNio库允许Java程序直接内存，从而提高性能，通常直接内存速度会优于Java堆。读写频繁的场合可能会考虑使用。

5、 每个虚拟机线程都有一个私有栈，一个线程的Java栈在线程创建的时候被创建，Java栈保存着局部变量、方法参数、同事Java的方法调用、

返回值等。

6、 本地方法栈，最大不同为本地方法栈用于本地方法调用。Java虚拟机允许Java直接调用本地方法（通过使用C语言写）

7、 垃圾收集系统是Java的核心，也是不可少的，Java有一套自己进行垃圾清理的机制，开发人员无需手工清理，下一节课详细讲。

8、 PC（Program Couneter）寄存器也是每个线程私有的空间， Java虚拟机会为每个线程创建PC寄存器，在任意时刻，

一个Java线程总是在执行一个方法，这个方法称为当前方法，如果当前方法不是本地方法，PC寄存器总会执行当前正在被执行的指令，

如果是本地方法，则PC寄存器值为Underfined，寄存器存放如果当前执行环境指针、程序技术器、操作栈指针、计算的变量指针等信息。

9、 虚拟机核心的组件就是执行引擎，它负责执行虚拟机的字节码，一般户先进行编译成机器码后执行。

Java堆

堆内存用于存放由new创建的对象和数组。在堆中分配的内存，由java虚拟机自动垃圾回收器来管理。在堆中产生了一个数组或者对象后，还可以在栈中定义一个特殊的变量，这个变量的取值等于数组或者对象在堆内存中的首地址，在栈中的这个特殊的变量就变成了数组或者对象的引用变量，以后就可以在程序中使用栈内存中的引用变量来访问堆中的数组或者对象，引用变量相当于为数组或者对象起的一个别名，或者代号。

 

根据垃圾回收机制的不同，Java堆有可能拥有不同的结构，最为常见的就是将整个Java堆分为

新生代和老年代。其中新声带存放新生的对象或者年龄不大的对象，老年代则存放老年对象。

新生代分为den区、s0区、s1区，s0和s1也被称为from和to区域，他们是两块大小相等并且可以互相角色的空间。

绝大多数情况下，对象首先分配在eden区，在新生代回收后，如果对象还存活，则进入s0或s1区，之后每经过一次

新生代回收，如果对象存活则它的年龄就加1，对象达到一定的年龄后，则进入老年代。

 

 

Java栈

Java栈是一块线程私有的空间，一个栈，一般由三部分组成:局部变量表、操作数据栈和帧数据区

局部变量表：用于报错函数的参数及局部变量

操作数栈：主要保存计算过程的中间结果，同时作为计算过程中的变量临时的存储空间。

帧数据区:除了局部变量表和操作数据栈以外，栈还需要一些数据来支持常量池的解析，这里帧数据区保存着

访问常量池的指针，方便计程序访问常量池，另外当函数返回或出现异常时卖虚拟机子必须有一个异常处理表，方便发送异常

的时候找到异常的代码，因此异常处理表也是帧数据区的一部分。

 

Java方法区和堆一样，方法区是一块所有线程共享的内存区域，他保存系统的类信息。

比如类的字段、方法、常量池等。方法区的大小决定系统可以保存多少个类。如果系统

定义太多的类，导致方法区溢出。虚拟机同样会抛出内存溢出的错误。方法区可以理解

为永久区。

 

虚拟机参数配置

在虚拟机运行的过程中，如果可以跟踪系统的运行状态，那么对于问题的故障

排查会有一定的帮助，为此，在虚拟机提供了一些跟踪系统状态的参数，使用

给定的参数执行Java虚拟机，就可以在系统运行时打印相关日志，用于分析实际

问题。我们进行虚拟机参数配置，其实就是围绕着堆、栈、方法区、进行配置。

你说下 你熟悉那些jvm参数调优

 

内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。

内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。

memory leak会最终会导致out of memory！

内存溢出就是你要求分配的内存超出了系统能给你的，系统不能满足需求，于是产生溢出。 

    内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。一个盘子用尽各种方法只能装4个果子，你装了5个，结果掉倒地上不能吃了。这就是溢出！比方说栈，栈满时再做进栈必定产生空间溢出，叫上溢，栈空时再做退栈也产生空间溢出，称为下溢。就是分配的内存不足以放下数据项序列,称为内存溢出. 

   以发生的方式来分类，内存泄漏可以分为4类： 

1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。 
2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。 
3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。 
4. 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。 

从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到 

 

引用计数法

概述

给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器都为0的对象就是不再被使用的，垃圾收集器将回收该对象使用的内存。

优缺点

优点：

引用计数收集器可以很快的执行，交织在程序运行中。对程序需要不被长时间打断的实时环境比较有利。

缺点：

无法检测出循环引用。如父对象有一个对子对象的引用，子对象反过来引用父对象。这样，他们的引用计数永远不可能为0.而且每次加减非常浪费内存。

 

标记清除算法

标记-清除（Mark-Sweep）算法顾名思义，主要就是两个动作，一个是标记，另一个就是清除。

标记就是根据特定的算法（如：引用计数算法，可达性分析算法等）标出内存中哪些对象可以回收，哪些对象还要继续用。

标记指示回收，那就直接收掉；标记指示对象还能用，那就原地不动留下。


缺点

  1. 1.  标记与清除效率低;
  2. 2.  清除之后内存会产生大量碎片；

所以碎片这个问题还得处理，怎么处理，看标记-整理算法。

复制算法

S0和s1将可用内存按容量分成大小相等的两块，每次只使用其中一块，当这块内存使用完了，就将还存活的对象复制到另一块内存上去，然后把使用过的内存空间一次清理掉。这样使得每次都是对其中一块内存进行回收，内存分配时不用考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

复制算法的缺点显而易见，可使用的内存降为原来一半。

复制算法用于在新生代垃圾回收

 

标记-压缩算法

标记压缩法在标记清除基础之上做了优化，把存活的对象压缩到内存一端,而后进行垃圾清理。(java中老年代使用的就是标记压缩法)

分代收集算法

根据内存中对象的存活周期不同，将内存划分为几块，java的虚拟机中一般把内存划分为新生代和年老代，当新创建对象时一般在新生代中分配内存空间，当新生代垃圾收集器回收几次之后仍然存活的对象会被移动到年老代内存中，当大对象在新生代中无法找到足够的连续内存时也直接在年老代中创建。

对于新生代和老年代来说,新生代回收频率很高,但是每次回收耗时很短,而老年代回收频率较低,但是耗时会相对较长,所以应该尽量减少老年代的GC.

 

垃圾收集器

Java垃圾回收器是Java虚拟机(JVM)的三个重要模块(另外两个是解释器和多线程机制)之一，为应用程序提供内存的自动分配(Memory Allocation)、自动回收(Garbage Collect)功能，这两个操作都发生在Java堆上(一段内存快)。某一个时点，一个对象如果有一个以上的引用(Rreference)指向它，那么该对象就为活着的(Live)，否则死亡(Dead)，视为垃圾，可被垃圾回收器回收再利用。垃圾回收操作需要消耗CPU、线程、时间等资源，所以容易理解的是垃圾回收操作不是实时的发生(对象死亡马上释放)，当内存消耗完或者是达到某一个指标(Threshold,使用内存占总内存的比列，比如0.75)时，触发垃圾回收操作。有一个对象死亡的例外，java.lang.Thread类型的对象即使没有引用，只要线程还在运行，就不会被回收。

串行回收器(Serial Collector)

单线程执行回收操作，回收期间暂停所有应用线程的执行，client模式下的默认回收器，通过-XX:+UseSerialGC命令行可选项强制指定。参数可以设置使用新生代串行和老年代串行回收器

年轻代的回收算法(Minor Collection)
把Eden区的存活对象移到To区，To区装不下直接移到年老代，把From区的移到To区，To区装不下直接移到年老代，From区里面年龄很大的升级到年老代。 回收结束之后，Eden和From区都为空，此时把From和To的功能互换，From变To，To变From，每一轮回收之前To都是空的。设计的选型为复制。

年老代的回收算法(Full Collection)
年老代的回收分为三个步骤，标记(Mark)、清除(Sweep)、合并(Compact)。标记阶段把所有存活的对象标记出来，清除阶段释放所有死亡的对象，合并阶段 把所有活着的对象合并到年老代的前部分，把空闲的片段都留到后面。设计的选型为合并，减少内存的碎片

。

并行回收

并行回收器(ParNew回收器)

并行回收器在串行回收器基础上做了改进，他可以使用多个线程同时进行垃
圾回收，对于计算能力强的计算机而言，可以有效的缩短垃圾回收所需的尖
际时间。
ParNew回收器是一个工作在新生代的垃圾收集器，他只是简单的将串行回收
器多线程快他的回收策略和算法和串行回收器一样。
使用XX:+UseParNewGC 新生代ParNew回收器，老年代则使用市行回收器
ParNew回收器工作时的线程数量可以使用XX:ParaleiGCThreads参数指
定，一般最好和计算机的CPU相当，避免过多的栽程影响性能。

 

并行回收集器(ParallelGC)

老年代ParallelOldGC回收器也是一种多线程的回收器，和新生代的
ParallelGC回收器一样，也是一种关往吞吐量的回收器，他使用了标记压缩
算法进行实现。
-XX:+UseParallelOldGC 进行设置
-XX:+ParallelCThread也可以设置垃圾收集时的线程教量。

 

并CMS(并发GC)收集器

CMS(Concurrent Mark
Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。CMS收集器是基于“标记-清除”算法实现的，整个收集过程大致分为4个步骤：

①.初始标记(CMS initial mark)

②.并发标记(CMS concurrenr mark)

③.重新标记(CMS remark)

④.并发清除(CMS concurrent sweep)

     其中初始标记、重新标记这两个步骤任然需要停顿其他用户线程。初始标记仅仅只是标记出GC ROOTS能直接关联到的对象，速度很快，并发标记阶段是进行GC ROOTS 根搜索算法阶段，会判定对象是否存活。而重新标记阶段则是为了修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间会被初始标记阶段稍长，但比并发标记阶段要短。

     由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以整体来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

CMS收集器的优点：并发收集、低停顿，但是CMS还远远达不到完美，器主要有三个显著缺点：

CMS收集器对CPU资源非常敏感。在并发阶段，虽然不会导致用户线程停顿，但是会占用CPU资源而导致引用程序变慢，总吞吐量下降。CMS默认启动的回收线程数是：(CPU数量+3) / 4。

CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure“，失败后而导致另一次Full  GC的产生。由于CMS并发清理阶段用户线程还在运行，伴随程序的运行自热会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在本次收集中处理它们，只好留待下一次GC时将其清理掉。这一部分垃圾称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，
即需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分内存空间提供并发收集时的程序运作使用。在默认设置下，CMS收集器在老年代使用了68%的空间时就会被激活，也可以通过参数-XX:CMSInitiatingOccupancyFraction的值来提供触发百分比，以降低内存回收次数提高性能。要是CMS运行期间预留的内存无法满足程序其他线程需要，就会出现“Concurrent Mode Failure”失败，这时候虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置的过高将会很容易导致“Concurrent Mode Failure”失败，性能反而降低。

最后一个缺点，CMS是基于“标记-清除”算法实现的收集器，使用“标记-清除”算法收集后，会产生大量碎片。空间碎片太多时，将会给对象分配带来很多麻烦，比如说大对象，内存空间找不到连续的空间来分配不得不提前触发一次Full  GC。为了解决这个问题，CMS收集器提供了一个-XX:UseCMSCompactAtFullCollection开关参数，用于在Full  GC之后增加一个碎片整理过程，还可通过-XX:CMSFullGCBeforeCompaction参数设置执行多少次不压缩的Full  GC之后，跟着来一次碎片整理过程。

 

G1回收器

G1回收器(Garbage-First)实在]dk1.7中提出的垃圾回收器，从长期目标来看是为了取
代CMS回收器，G1回收器拥有独特的垃圾回收策略，G1属于分代垃圾回收器，区分
新生代和老年代，依然有eden和from/to区,它并不要求整个eden区或者新生代、老
年代的空间都连续，它使用了分区算法。
并行性: G1回收期间可多线程同时工作。
井发性G1拥有与应用程序交替执行能力，部分工作可与应用程序同时执行，在整个
GC期间不会完全阻塞应用程序。
分代GC:G1依然是一个分代的收集器，但是它是非两新生代和老年代一杯政的杂尊。
空间基理，G1在国收过程中，不会微CMS那样在若千tacAy 要进行碎片整理。
G1
来用了有效复制对象的方式，减少空间碎片。
利得程，用于分区的原因，G可以贝造取都分区城进行回收，帽小了国收的格想，
提升了性能。
使用.XXX:+UseG1GC 应用G1收集器，
Mills指定最大停顿时间
使用-XX:MaxGCPausel
设置并行回收的线程数量
使用-XX:ParallelGCThreads

 

 

 

微服务与分布式

RPC 的全称是 Remote
Procedure Call 是一种进程间通信方式。
它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即无论是调用本地接口/服务的还是远程的接口/服务，本质上编写的调用代码基本相同。
比如两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数或者方法，由于不在一个内存空间，不能直接调用，这时候需要通过就可以应用RPC框架的实现来解决

SOA是一种面向服务架构，是将相同业务逻辑抽取出来组成单独服务。

SOAP是WebService面向服务协议，
采用xml,因为比较中，现在不是特别流行。

微服务架构师一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相

协调、互相配合没用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的同学机制互相沟通(通畅采用Http+restful API)，每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生成环境、类生存环境等。另外，应尽量避免同一的、集中式服务管理机制。

SOA实现

微服务架构实现

企业级，自顶向下开展实施

团队级，自定向上开展实施

服务由多个子系统组成

一个系统被拆分成多个服务

集成式服务(esb、ws、soap)

集成方式简单(http、rest、json)

 

SpringCloud、Dubbo、Dubbox、Hessian、HttpClient、thrift等。

 

SpringCloud
为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现(Eureka)、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。它运行环境简单，可以在开发人员的电脑上跑。另外说明spring cloud是基于Springboot的，所以需要开发中对Springboot有一定的了解，如果不了解的话可以看蚂蚁课堂SpringBoot课程。

SpringCloud使用Eureka作为注册中心，使用rest+ribbon或者feign，断路器Hystrix、zuul接口网关等。

Duubbo是一个RPC远程调用框架，
分布式服务治理框架

什么是Dubbo服务治理？

服务与服务之间会有很多个Url、依赖关系、负载均衡、容错、自动注册服务。

默认用的dubbo协议、Http、RMI、Hessian

分为四大模块

生产者、消费者、注册中心、监控中心

生产者：提供服务

消费者: 调用服务

注册中心:注册信息(redis、zk)

监控中心:调用次数、关系依赖等。

首先生产者将服务注册到注册中心（zk），使用zk持久节点进行存储，消费订阅zk节点，一旦有节点变更，zk通过事件通知传递给消费者，消费可以调用生产者服务。

服务与服务之间进行调用，都会在监控中心中，存储一个记录。

 

Dubox使用http协议+rest风格传入json或者xml格式进行远程调用。

Dubbo使用Dubbo协议。

相同点:

dubbo与springcloud都可以实现RPC远程调用。

dubbo与springcloud都可以使用分布式、微服务场景下。

区别:

dubbo有比较强的背景,在国内有一定影响力。

dubbo使用zk或redis作为作为注册中心

springcloud使用eureka作为注册中心

dubbo支持多种协议，默认使用dubbo协议。

Springcloud只能支持http协议。

Springcloud是一套完整的微服务解决方案。

Dubbo目前已经停止更新,SpringCloud更新速度快。

 

Zookeeper是一个工具，可以实现集群中的分布式协调服务。

所谓的分布式协调服务，就是在集群的节点中进行可靠的消息传递，来协调集群的工作。

 

Zookeeper之所以能够实现分布式协调服务，靠的就是它能够保证分布式数据一致性。

所谓的分布式数据一致性，指的就是可以在集群中保证数据传递的一致性。

 Zookeeper能够提供的分布式协调服务包括：数据发布订阅、负载均衡、命名服务、分布式协调/通知、集群管理、分布式锁、分布式队列等功能

 

Zookeeper工作在集群中，对集群提供分布式协调服务，它提供的分布式协调服务具有如下的特点：

顺序一致性

从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到zookeeper中

原子性

所有事物请求的处理结果在整个集群中所有机器上的应用情况是一致的，即，要么整个集群中所有机器都成功应用了某一事务，要么都没有应用，一定不会出现集群中部分机器应用了改事务，另外一部分没有应用的情况。

单一视图

无论客户端连接的是哪个zookeeper服务器，其看到的服务端数据模型都是一致的。

可靠性

一旦服务端成功的应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直保留下来，除非有另一个事务又对其进行了改变。

实时性

zookeeper并不是一种强一致性，只能保证顺序一致性和最终一致性，只能称为达到了伪实时性。

zookeeper的数据模型

zookeepei中可以保存数据，正是利用zookeeper可以保存数据这一特点，我们的集群通过在zookeeper里存取数据来进行消息的传递。

zookeeper中保存数据的结构非常类似于文件系统。都是由节点组成的树形结构。不同的是文件系统是由文件夹和文件来组成的树，而zookeeper中是由ZNODE来组成的树。

每一个ZNODE里都可以存放一段数据，ZNODE下还可以挂载零个或多个子ZNODE节点，从而组成一个树形结构。

 

数据发布订阅

负载均衡

命名服务

分布式协调

集群管理

配置管理

分布式队列

分布式锁

 

简单的理解就是：分布式锁是一个在很多环境中非常有用的原语，它是不同的系统或是同一个系统的不同主机之间互斥操作共享资源的有效方法。

分布式锁使用zk，在zk上创建一个临时节点，使用临时节点作为锁，因为节点不允许重复。

如果能创建节点成功，生成订单号，如果创建节点失败，就等待。临时节点zk关闭，释放锁，其他节点就可以重新生成订单号。

 

一般的锁只能针对单机下同一进程的多个线程，或单机的多个进程。多机情况下，对同一个资源访问，需要对每台机器的访问进程或线程加锁，这便是分布式锁。分布式锁可以利用多机的共享缓存（例如redis）实现。redis的命令文档[1]，实现及分析参考文档[2]。

利用redis的get、setnx、getset、del四个命令可以实现基于redis的分布式锁：

get key：表示从redis中读取一个key的value，如果key没有对应的value，返回nil，如果存储的值不是字符串类型，返回错误

setnx key value：表示往redis中存储一个键值对，但只有当key不存在时才成功，返回1；否则失败，返回0，不改变key的value

getset key：将给定 key 的值设为 value ，并返回 key 的旧值(old
value)。当旧值不存在时返回nil，当旧值不为字符串类型，返回错误

del key：表示删除key，当key不存在时不做操作，返回删除的key数量

关于加锁思考，循环中： 
0、setnx的value是当前机器时间+预估运算时间作为锁的失效时间。这是为了防止获得锁的线程挂掉而无法释放锁而导致死锁。 
0.1、返回1，证明已经获得锁，返回啦 
0.2、返回0，获得锁失败，需要检查锁超时时间 
1、get 获取到锁，利用失效时间判断锁是否失效。 
1.1、取锁超时时间的时刻可能锁被删除释放，此时并没有拿到锁，应该重新循环加锁逻辑。 
2、取锁超时时间成功 
2.1、锁没有超时，休眠一下，重新循环加锁 
2.2、锁超时，但此时不能直接释放锁删除。因为此时可能多个线程都读到该锁超时，如果直接删除锁，所有线程都可能删除上一个删除锁又新上的锁，会有多个线程进入临界区，产生竞争状态。 
3、此时采用乐观锁的思想，用getset再次获取锁的旧超时时间。 
3.1、如果此时获得锁旧超时时间成功 
3.1.1、等于上一次获得的锁超时时间，证明两次操作过程中没有别人动过这个锁，此时已经获得锁 
3.1.2、不等于上一次获得的锁超时时间，说明有人先动过锁，获取锁失败。虽然修改了别人的过期时间，但因为冲突的线程相差时间极短，所以修改后的过期时间并无大碍。此处依赖所有机器的时间一致。 
3.2、如果此时获得锁旧超时时间失败，证明当前线程是第一个在锁失效后又加上锁的线程，所以也获得锁 
4、其他情况都没有获得锁，循环setnx吧

关于解锁的思考： 
在锁的时候，如果锁住了，回传超时时间，作为解锁时候的凭证，解锁时传入锁的键值和凭证。我思考的解锁时候有两种写法： 
1、解锁前get一下键值的value，判断是不是和自己的凭证一样。但这样存在一些问题：

get时返回nil的可能，此时表示有别的线程拿到锁并用完释放

get返回非nil，但是不等于自身凭证。由于有getset那一步，当两个竞争线程都在这个过程中时，存在持有锁的线程凭证不等于value，而是value是稍慢那一步线程设置的value。

2、解锁前用凭证判断锁是否已经超时，如果没有超时，直接删除；如果超时，等着锁自动过期就好，免得误删别人的锁。但这种写法同样存在问题，由于线程调度的不确定性，判断到删除之间可能过去很久，并不是绝对意义上的正确解锁。

 

public class RedisLock {

 

   
private static final Logger logger =
LoggerFactory.getLogger(RedisLock.class);

 

   
//显然jedis还需要自己配置来初始化

   
private Jedis jedis = new Jedis();

 

   
//默认锁住15秒，尽力规避锁时间太短导致的错误释放

   
private static final long DEFAULT_LOCK_TIME = 15 * 1000;

 

   
//尝试锁住一个lock，设置尝试锁住的次数和超时时间（毫秒）,默认最短15秒

   
//成功时返回这把锁的key，解锁时需要凭借锁的lock和key

   
//失败时返回空字符串

   
public String lock(String lock, int retryCount, long timeout) {

       
Preconditions.checkArgument(retryCount > 0 && timeout > 0, “retry count <= 0 or timeout
<= 0 !”);

       
Preconditions.checkArgument(retryCount < Integer.MAX_VALUE
&& timeout < Long.MAX_VALUE – DEFAULT_LOCK_TIME,

                “retry count is too big or
timeout is too big!”);

       
String $lock = Preconditions.checkNotNull(lock) + “_redis_lock”;

       
long $timeout = timeout +
DEFAULT_LOCK_TIME;

       
String ret = null;

       
//重试一定次数，还是拿不到，就放弃

       
try {

            long i, status;

            for (i = 0, status = 0; status == 0 && i < retryCount; ++i) {

                //尝试加锁，并设置超时时间为当前机器时间+超时时间

                if ((status = jedis.setnx($lock, ret =
Long.toString(System.currentTimeMillis() + $timeout))) == 0) {

                    //获取锁失败，查看锁是否超时

                    String time = jedis.get($lock);

                    //在加锁和检查之间，锁被删除了，尝试重新加锁

                    if (time == null) {

                        continue;

                    }

                    //锁的超时时间戳小于当前时间，证明锁已经超时

                    if (Long.parseLong(time) <
System.currentTimeMillis()) {

                        String oldTime =
jedis.getSet($lock,
Long.toString(System.currentTimeMillis() + $timeout));

                        if (oldTime == null || oldTime.equals(time)) {

                            //拿到锁了，跳出循环

                            break;

                        }

                    }

                    try {

                       
TimeUnit.MILLISECONDS.sleep(1L);

                    } catch (InterruptedException e) {

      
                 logger.error(“lock key:{} sleep failed!”, lock);

                    }

                }

            }

            if (i == retryCount && status ==
0) {

                logger.info(“lock key:{} failed!”, lock);

                return “”;

            }

            //给锁加上过期时间

            jedis.pexpire($lock, $timeout);

            logger.info(“lock key:{} succsee!”, lock);

            return ret;

       
} catch (Exception e) {

            logger.error(“redis lock key:{} failed! cached
exception: “,
lock, e);

            return “”;

       
}

   
}

 

   
//释放lock的锁，需要传入lock和key

   
//尽力确保删除属于自己的锁，但是不保证做得到

   
public void releaseLock(String lock, String key) {

       
String $lock = Preconditions.checkNotNull(lock) + “_redis_lock”;

       
Preconditions.checkNotNull(key);

       
try {

            long timeout = Long.parseLong(key);

            //锁还没有超时，锁还属于自己可以直接删除

            //但由于线程运行的不确定性，其实不能完全保证删除时锁还属于自己

            //真正执行删除操作时，距离上语句判断可能过了很久

            if (timeout <=
System.currentTimeMillis()) {

                jedis.del($lock);

                logger.info(“release lock:{} with key:{}
success!”,
lock, key);

            } else {

                logger.info(“lock:{} with key:{} timeout!
wait to expire”, lock, key);

            }

       
} catch (Exception e) {

            logger.error(“redis release {}  with key:{} failed! cached exception:
“, lock, key, e);

       
}

   
}

}

 

基于缓存实现分布式锁

 锁没有失效事件,容易死锁

 非阻塞式

不可重入

基于Zookeeper实现分布式锁

 实现相对简单

 可靠性高

 性能较好

 

Thread

publicclass Demo01 {

     staticlongcount = 0;

     publicstaticvoid main(String[] args) {

          Runnable
runnable = new Runnable() {

               @Override

               publicvoid run() {

                    while (true) {

                         try {

                              Thread.sleep(1000);

                              count++;

                              System.out.println(count);

                         }
catch (Exception e) {

                              // TODO: handle exception

                         }

                    }

               }

          };

          Thread
thread = new Thread(runnable);

          thread.start();

     }

}

 

TimerTask

/**

 * 使用TimerTask类实现定时任务

*/

publicclass Demo02 {

     staticlongcount = 0;

 

     publicstaticvoid main(String[] args) {

          TimerTask
timerTask = new TimerTask() {

 

               @Override

               publicvoid run() {

                    count++;

                    System.out.println(count);

               }

          };

          Timer
timer = new Timer();

          // 天数

          longdelay = 0;

          // 秒数

          longperiod = 1000;

          timer.scheduleAtFixedRate(timerTask, delay, period);

     }

 

}

 

 

ScheduledExecutorService

使用ScheduledExecutorService是从Java

JavaSE5的java.util.concurrent里，做为并发工具类被引进的，这是最理想的定时任务实现方式。

publicclass Demo003 {

     publicstaticvoid main(String[] args) {

          Runnable
runnable = new Runnable() {

               publicvoid run() {

                    // task to run goes here

                    System.out.println(“Hello !!”);

               }

          };

          ScheduledExecutorService
service = Executors.newSingleThreadScheduledExecutor();

          // 第二个参数为首次执行的延时时间，第三个参数为定时执行的间隔时间

          service.scheduleAtFixedRate(runnable, 1, 1, TimeUnit.SECONDS);

     }

}

 

Quartz

创建一个quartz_demo项目

引入maven依赖

     <dependencies>

          <!– quartz –>

          <dependency>

               <groupId>org.quartz-scheduler</groupId>

               <artifactId>quartz</artifactId>

               <version>2.2.1</version>

          </dependency>

          <dependency>

               <groupId>org.quartz-scheduler</groupId>

               <artifactId>quartz-jobs</artifactId>

               <version>2.2.1</version>

          </dependency>

     </dependencies>

 

任务调度类

publicclass MyJob implements Job {

 

     publicvoid execute(JobExecutionContext context) throws JobExecutionException {

          System.out.println(“quartz MyJob date:” + new Date().getTime());

     }

 

}

 

启动类

 
//1.创建Scheduler的工厂

      SchedulerFactory sf = new
StdSchedulerFactory();

      //2.从工厂中获取调度器实例

      Scheduler scheduler = sf.getScheduler();

 

 

      //3.创建JobDetail

      JobDetail jb = JobBuilder.newJob(MyJob.class)

              .withDescription(“this is a ram job”) //job的描述

              .withIdentity(“ramJob”, “ramGroup”) //job 的name和group

              .build();

 

      //任务运行的时间，SimpleSchedle类型触发器有效

      longtime= 
System.currentTimeMillis() + 3*1000L; //3秒后启动任务

      Date statTime = new Date(time);

 

      //4.创建Trigger

          //使用SimpleScheduleBuilder或者CronScheduleBuilder

      Trigger t = TriggerBuilder.newTrigger()

                  .withDescription(“”)

                  .withIdentity(“ramTrigger”, “ramTriggerGroup”)

                  //.withSchedule(SimpleScheduleBuilder.simpleSchedule())

                  .startAt(statTime) 
//默认当前时间启动

                 
.withSchedule(CronScheduleBuilder.cronSchedule(“0/2 * * * * ?”)) //两秒执行一次

                  .build();

 

      //5.注册任务和定时器

      scheduler.scheduleJob(jb, t);

 

      //6.启动调度器

     
scheduler.start();

 

分布式集群的情况下，怎么保证定时任务不被重复执行

①使用zookeeper实现分布式锁 缺点(需要创建临时节点、和事件通知不易于扩展)

②使用配置文件做一个开关  缺点发布后，需要重启

③数据库唯一约束，缺点效率低

④使用分布式任务调度平台

  XXLJOB

 

 全局事物

使用全局事物两段提交协议，遵循XA协议规范，使用开源框架jta+automatic 。

什么是两段提交协议：在第一阶段，所有参与全局事物的节点都开始准备,告诉事物管理器

它们准备好了，在是第二阶段，事物管理器告诉资源执行ROLLBACK还是Commit，只要任何一方为ROLLBACK ，则直接回滚。

参考案例：springboot集成automatic+jta

 

本地消息表

这种实现方式的思路，其实是源于ebay，后来通过支付宝等公司的布道，在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。如果不考虑性能及设计优雅，借助关系型数据库中的表即可实现。

举个经典的跨行转账的例子来描述。

第一步，伪代码如下，扣款1W，通过本地事务保证了凭证消息插入到消息表中。 

第二步，通知对方银行账户上加1W了。那问题来了，如何通知到对方呢？

通常采用两种方式：

1. 采用时效性高的MQ，由对方订阅消息并监听，有消息时自动触发事件 
2. 采用定时轮询扫描的方式，去检查消息表的数据。

两种方式其实各有利弊，仅仅依靠MQ，可能会出现通知失败的问题。而过于频繁的定时轮询，效率也不是最佳的（90%是无用功）。所以，我们一般会把两种方式结合起来使用。

解决了通知的问题，又有新的问题了。万一这消息有重复被消费，往用户帐号上多加了钱，那岂不是后果很严重？

仔细思考，其实我们可以消息消费方，也通过一个“消费状态表”来记录消费状态。在执行“加款”操作之前，检测下该消息（提供标识）是否已经消费过，消费完成后，通过本地事务控制来更新这个“消费状态表”。这样子就避免重复消费的问题。

总结：上诉的方式是一种非常经典的实现，基本避免了分布式事务，实现了“最终一致性”。但是，关系型数据库的吞吐量和性能方面存在瓶颈，频繁的读写消息会给数据库造成压力。所以，在真正的高并发场景下，该方案也会有瓶颈和限制的。

 

MQ(非事物)

通常情况下，在使用非事务消息支持的MQ产品时，我们很难将业务操作与对MQ的操作放在一个本地事务域中管理。通俗点描述，还是以上述提到的“跨行转账”为例，我们很难保证在扣款完成之后对MQ投递消息的操作就一定能成功。这样一致性似乎很难保证。 
先从消息生产者这端来分析，请看伪代码：

 

根据上述代码及注释，我们来分析下可能的情况：

1. 操作数据库成功，向MQ中投递消息也成功，皆大欢喜 
2. 操作数据库失败，不会向MQ中投递消息了 
3. 操作数据库成功，但是向MQ中投递消息时失败，向外抛出了异常，刚刚执行的更新数据库的操作将被回滚

从上面分析的几种情况来看，貌似问题都不大的。那么我们来分析下消费者端面临的问题：

1. 消息出列后，消费者对应的业务操作要执行成功。如果业务执行失败，消息不能失效或者丢失。需要保证消息与业务操作一致 
2. 尽量避免消息重复消费。如果重复消费，也不能因此影响业务结果

如何保证消息与业务操作一致，不丢失？

主流的MQ产品都具有持久化消息的功能。如果消费者宕机或者消费失败，都可以执行重试机制的（有些MQ可以自定义重试次数）。

如何避免消息被重复消费造成的问题？

1. 保证消费者调用业务的服务接口的幂等性 
2. 通过消费日志或者类似状态表来记录消费状态，便于判断（建议在业务上自行实现，而不依赖MQ产品提供该特性）

总结：这种方式比较常见，性能和吞吐量是优于使用关系型数据库消息表的方案。如果MQ自身和业务都具有高可用性，理论上是可以满足大部分的业务场景的。不过在没有充分测试的情况下，不建议在交易业务中直接使用。

 

MQ（事务消息）

其他补偿方式

做过支付宝交易接口的同学都知道，我们一般会在支付宝的回调页面和接口里，解密参数，然后调用系统中更新交易状态相关的服务，将订单更新为付款成功。同时，只有当我们回调页面中输出了success字样或者标识业务处理成功相应状态码时，支付宝才会停止回调请求。否则，支付宝会每间隔一段时间后，再向客户方发起回调请求，直到输出成功标识为止。 
其实这就是一个很典型的补偿例子，跟一些MQ重试补偿机制很类似。

一般成熟的系统中，对于级别较高的服务和接口，整体的可用性通常都会很高。如果有些业务由于瞬时的网络故障或调用超时等问题，那么这种重试机制其实是非常有效的。

当然，考虑个比较极端的场景，假如系统自身有bug或者程序逻辑有问题，那么重试1W次那也是无济于事的。那岂不是就发生了“明明已经付款，却显示未付款不发货”类似的悲剧？

其实为了交易系统更可靠，我们一般会在类似交易这种高级别的服务代码中，加入详细日志记录的，一旦系统内部引发类似致命异常，会有邮件通知。同时，后台会有定时任务扫描和分析此类日志，检查出这种特殊的情况，会尝试通过程序来补偿并邮件通知相关人员。

在某些特殊的情况下，还会有“人工补偿”的，这也是最后一道屏障。

补充资料

 

一、协议概述

　两阶段提交协议（two
phase commit protocol，2PC）可以保证数据的强一致性，许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者，并决定提交或取消（回滚）的分布式算法。同时也是解决一致性问题的一致性算法。该算法能够解决很多的临时性系统故障（包括进程、网络节点、通信等故障），被广泛地使用。但是，它并不能够通过配置来解决所有的故障，在某些情况下它还需要人为的参与才能解决问题。参与者为了能够从故障中恢复，它们都使用日志来记录协议的状态，虽然使用日志降低了性能但是节点能够从故障中恢复。

　　在两阶段提交协议中，系统一般包含两类机器（或节点）：
　　①协调者coordinator，通常一个系统中只有一个；
　　②事务参与者 participants，cohorts或workers，一般包含多个；
　　在数据存储系统中可以理解为数据副本的个数，协议中假设：
　　①每个节点都会记录写前日志并持久性存储，即使节点发生故障日志也不会丢失；
　　②节点不会发生永久性故障而且任意两个节点都可以互相通信；

　　当事务的最后一步完成之后，协调器执行协议，参与者根据本地事务，能够成功完成回复同意提交事务或者回滚事务。

二、执行过程

　　顾名思义，两阶段提交协议由两个阶段组成。在正常的执行下，这两个阶段的执行过程如下所述：

（1）阶段1：请求阶段（commit-request phase，或称表决阶段，voting phase）

　　在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。

（2）阶段2：提交阶段（commit phase）

　　在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。

　　注意  两阶段提交协议与两阶段锁协议不同，两阶段锁协议为一致性控制协议。

（3）该协议的执行过程可以通过下图来描述：

 

 
             （a）成功                 
                 （b）失败

三、协议的特点

　　两阶段提交协议最大的劣势是其通过阻塞完成的协议，在节点等待消息的时候处于阻塞状态，节点中其他进程则需要等待阻塞进程释放资源才能使用。如果协调器发生了故障，那么参与者将无法完成事务则一直等待下去。以下情况可能会导致节点发生永久阻塞：

　　（1）如果参与者发送同意提交消息给协调者，进程将阻塞直至收到协调器的提交或回滚的消息。如果协调器发生永久故障，参与者将一直等待，这里可以采用备份的协调器，所有参与者将回复发给备份协调器，由它承担协调器的功能。

　　（2）如果协调器发送“请求提交”消息给参与者，它将被阻塞直到所有参与者回复了，如果某个参与者发生永久故障，那么协调器也不会一直阻塞，因为协调器在某一时间内还未收到某参与者的消息，那么它将通知其他参与者回滚事务。

　　同时两阶段提交协议没有容错机制，一个节点发生故障整个事务都要回滚，代价比较大。

四、工作过程

　　下面我们通过一个例子来说明两阶段提交协议的工作过程：

　　A组织B、C和D三个人去爬长城：如果所有人都同意去爬长城，那么活动将举行；如果有一人不同意去爬长城，那么活动将取消。用2PC算法解决该问题的过程如下：

　　首先A将成为该活动的协调者，B、C和D将成为该活动的参与者。

（1）阶段1：

　　①A发邮件给B、C和D，提出下周三去爬山，问是否同意。那么此时A需要等待B、C和D的邮件。

　　②B、C和D分别查看自己的日程安排表。B、C发现自己在当日没有活动安排，则发邮件告诉A它们同意下周三去爬长城。由于某种原因， D白天没有查看邮 件。那么此时A、B和C均需要等待。到晚上的时候，D发现了A的邮件，然后查看日程安排，发现周三当天已经有别的安排，那么D回复A说活动取消吧。

（2）阶段2：

　　①此时A收到了所有活动参与者的邮件，并且A发现D下周三不能去爬山。那么A将发邮件通知B、C和D，下周三爬长城活动取消。

　　②此时B、C回复A“太可惜了”，D回复A“不好意思”。至此该事务终止。

　　通过该例子可以发现，2PC协议存在明显的问题。假如D一直不能回复邮件，那么A、B和C将不得不处于一直等待的状态。并且B和C所持有的资源，即下周三不能安排其它活动，一直不能释放。其它等待该资源释放的活动也将不得不处于等待状态。

　　基于此，后来有人提出了三阶段提交协议，在其中引入超时的机制，将阶段1分解为两个阶段：在超时发生以前，系统处于不确定阶段；在超市发生以后，系统则转入确定阶段。

　　2PC协议包含协调者和参与者，并且二者都有发生问题的可能性。假如协调者发生问题，我们可以选出另一个协调者来提交事务。例如，班长组织活动，如果班长生病了，我们可以请副班长来组织。如果协调者出问题，那么事务将不会取消。例如，班级活动希望每个人都能去，假如有一位同学不能去了，那么直接取消活动即可。或者，如果大多数人去的话那么活动如期举行（2PC变种）。为了能够更好地解决实际的问题，2PC协议存在很多的变种，例如：树形2PC协议 （或称递归2PC协议）、动态2阶段提交协议（D2PC）等。

项目问题

支付项目支付流程

 

 

 

产生：第三方支付网关，重试机制造成幂等性

判断支付结果标识 注意：回调接口中，如果调用耗时代码，使用mq异步推送

Token、对称加密  base64 加签、rsa

使用对账（第三方支付交易接口），去进行查询。

对账（第三方交易平台交易结果）

 

 

联合登录步骤：

蚂蚁课堂生成授权连接，跳转到腾讯企业

选择授权QQ用户,授权成功后，就会跳转到原地址

 

 

 

授权连接：

回调地址 ：授权成功后,跳转到回调地址

跳转到回调地址：传一些参数

 

 

跳转到回调地址：

传一个授权code有效期 10分钟 
授权code使用完毕之后，直接删除，不能重复使用

授权码的作用：使用授权码换取aess_token，使用aess_token换取openid

 

openid作用: 唯一用户主键（授权系统会员主键，不代码腾讯userid）

 

 

 

openid和我们用户表中存放一个openid进行关联

 

使用openid调用腾讯会员接口查询QQ信息

本地回调

 

你们登录流程

 

 

你在开发中遇到了那些难题，是怎么解决的？

跨域

跨域原因产生：在当前域名请求网站中，默认不允许通过ajax请求发送其他域名。

XMLHttpRequest cannot load 跨域问题解决办法

使用后台response添加header

后台response添加header，response.setHeader(“Access-Control-Allow-Origin”,
“*”); 支持所有网站

 

使用JSONP

JSONP的优缺点:

JSONP只支持get请求不支持psot请求

什么是SQL语句注入

 

使用接口网关

使用nginx转发。

配置:

server {

        listen       80;

        server_name  www.itmayiedu.com;

        location /A {

                  proxy_pass  http://a.a.com:81/A;

                     index  index.html index.htm;

        }

              location /B {

                  proxy_pass  http://b.b.com:81/B;

                     index  index.html index.htm;

        }

    }

 

相关图:

 

 

使用内部服务器转发

 内部服务器使用HttpClient技术进行转发

 

 

同步接口中保证数据一致性问题

例如A调用B接口，B接口没有及时反应，怎么进行补偿？

日志记录，任务调度定时补偿，自动重试机制。

 

①使用zookeeper实现分布式锁 缺点(需要创建临时节点、和事件通知不易于扩展)

②使用配置文件做一个开关  缺点发布后，需要重启

③数据库唯一约束，缺点效率低

④使用分布式任务调度平台

  XXLJOB

解决办法:

①   
使用日志+msg-id保存报文信息，作为去重和幂等的依据。

②   
消费端代码抛出异常，不需要重试补偿，使用日志记录报文，下次发版本解决。

 

q

版权声明：本文为bob1原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://www.cnblogs.com/bob1/p/12872586.html