这个是真的厉害，高并发场景下的订单和库存处理方案，讲的很详细

发表于 2020-07-15

前言

之前一直有小伙伴私信我问我高并发场景下的订单和库存处理方案，我最近也是因为加班的原因比较忙，就一直没来得及回复。今天好不容易闲了下来想了想不如写篇文章把这些都列出来的，让大家都能学习到，说一千道一万都不如满满的干货来的实在，干货都下面了！

介绍

前提：分布式系统，高并发场景
商品A只有100库存，现在有1000或者更多的用户购买。如何保证库存在高并发的场景下是安全的。
预期结果：1.不超卖 2.不少卖 3.下单响应快 4.用户体验好

下单思路：

下单时生成订单，减库存，同时记录库存流水，在这里需要先进行库存操作再生成订单数据，这样库存修改成功，响应超时的特殊情况也可以通过第四步定时校验库存流水来完成最终一致性。
支付成功删除库存流水，处理完成删除可以让库存流水数据表数据量少，易于维护。
未支付取消订单，还库存+删除库存流水
定时校验库存流水，结合订单状态进行响应处理，保证最终一致性

（退单有单独的库存流水，申请退单插入流水，退单完成删除流水+还库存）

什么时候进行减库存

方案一：加购时减库存。
方案二：确认订单页减库存。
方案三：提交订单时减库存。
方案四：支付时减库存。

分析：

方案一：在这个时间内加入购物车并不代表用户一定会购买,如果这个时候处理库存，会导致想购买的用户显示无货。而不想购买的人一直占着库存。显然这种做法是不可取的。唯品会购物车锁库存，但是他们是另一种做法，加入购物车后会有一定时效，超时会从购物车清除。
方案二：确认订单页用户有购买欲望，但是此时没有提交订单，减库存会增加很大的复杂性，而且确认订单页的功能是让用户确认信息，减库存不合理，希望大家对该方案发表一下观点，本人暂时只想到这么多。
方案三：提交订单时减库存。用户选择提交订单，说明用户有强烈的购买欲望。生成订单会有一个支付时效，例如半个小时。超过半个小时后，系统自动取消订单，还库存。
方案四：支付时去减库存。比如：只有100个用户可以支付，900个用户不能支付。用户体验太差，同时生成了900个无效订单数据。

所以综上所述：
选择方案三比较合理。

重复下单问题

用户点击过快，重复提交。
网络延时，用户重复提交。
网络延时高的情况下某些框架自动重试，导致重复请求。
用户恶意行为。

解决办法

前端拦截，点击后按钮置灰。
后台：
(1）redis 防重复点击，在下单前获取用户token，下单的时候后台系统校验这个 token是否有效，导致的问题是一个用户多个设备不能同时下单。

1 2	复制代码 //key , 等待获取锁的时间，锁的时间 redis.lock("shop-oms-submit" + token, 1L, 10L);

redis的key用token + 设备编号一个用户多个设备可以同时下单。

1 2	复制代码 //key , 等待获取锁的时间，锁的时间 redis.lock("shop-oms-submit" + token + deviceType, 1L, 10L);

（2）防止恶意用户，恶意攻击：一分钟调用下单超过50次，加入临时黑名单，10分钟后才可继续操作，一小时允许一次跨时段弱校验。使用reids的list结构，过期时间一小时

复制代码/**
     * @param token
     * @return true 可下单
     */
    public boolean judgeUserToken(String token) {
        //获取用户下单次数 1分钟50次
        String blackUser = "shop-oms-submit-black-" + token;
        if (redis.get(blackUser) != null) {
            return false;
        }
        String keyCount = "shop-oms-submit-count-" + token;
        Long nowSecond = LocalDateTime.now().toEpochSecond(ZoneOffset.of("+8"));
        //每一小时清一次key 过期时间1小时
        Long count = redis.rpush(keyCount, String.valueOf(nowSecond), 60 * 60);
        if (count < 50) {
            return true;
        }
        //获取第50次的时间
        List<String> secondString = redis.lrange(keyCount, count - 50, count - 49);
        Long oldSecond = Long.valueOf(secondString.get(0));
        //now > oldSecond + 60 用户可下单
        boolean result = nowSecond.compareTo(oldSecond + 60) > 0;
        if (!result) {
            //触发限制，加入黑名单，过期时间10分钟
            redis.set(blackUser, String.valueOf(nowSecond), 10 * 60);
        }
        return result;
    }

如何安全的减库存

多用户抢购时，如何做到并发安全减库存？

方案1：数据库操作商品库存采用乐观锁防止超卖：

1	复制代码sql:update sku_stock set stock = stock - num where sku_code = '' and stock - num > 0;

分析：
高并发场景下，假设库存只有 1件，两个请求同时进来，抢购该商品.
数据库层面会限制只有一个用户扣库存成功。在并发量不是很大的情况下可以这么做。但是如果是秒杀，抢购，瞬时流量很高的话，压力会都到数据库，可能拖垮数据库。

方案2：利用Redis单线程强制串行处理

复制代码/**
     * 缺点并发不高,同时只能一个用户抢占操作,用户体验不好！
     *
     * @param orderSkuAo
     */
    public boolean subtractStock(OrderSkuAo orderSkuAo) {
        String lockKey = "shop-product-stock-subtract" + orderSkuAo.getOrderCode();
        if(redis.get(lockKey)){
            return false;
        }
        try {
            lock.lock(lockKey, 1L, 10L);
            //处理逻辑
        }catch (Exception e){
            LogUtil.error("e=",e);
        }finally {
            lock.unLock(lockKey);
        }
        return true;
    }

分析：
利用Redis 分布式锁,强制控制同一个商品处理请求串行化，缺点并发不高，处理比较慢，不适合抢购，高并发场景。用户体验差，但是减轻了数据库的压力。

方案3 ：redis + mq + mysql 保证库存安全，满足高并发处理，但相对复杂。

复制代码     /**
     * 扣库存操作,秒杀的处理方案
     * @param orderCode
     * @param skuCode
     * @param num
     * @return
     */
    public boolean subtractStock(String orderCode,String skuCode, Integer num) {
        String key = "shop-product-stock" + skuCode;
        Object value = redis.get(key);
        if (value == null) {
            //前提 提前将商品库存放入缓存 ,如果缓存不存在，视为没有该商品
            return false;
        }
        //先检查 库存是否充足
        Integer stock = (Integer) value;
        if (stock < num) {
            LogUtil.info("库存不足");
            return false;
        } 
       //不可在这里直接操作数据库减库存，否则导致数据不安全
       //因为此时可能有其他线程已经将redis的key修改了
        //redis 减少库存，然后才能操作数据库
        Long newStock = redis.increment(key, -num.longValue());
        //库存充足
        if (newStock >= 0) {
            LogUtil.info("成功抢购");
            //TODO 真正扣库存操作 可用MQ 进行 redis 和 mysql 的数据同步，减少响应时间
        } else {
            //库存不足，需要增加刚刚减去的库存
            redis.increment(key, num.longValue());
            LogUtil.info("库存不足,并发");
            return false;
        }
        return true;
    }

分析：
利用Redis increment 的原子操作，保证库存安全，利用MQ保证高并发响应时间。但是事需要把库存的信息保存到Redis，并保证Redis 和 Mysql 数据同步。缺点是redis宕机后不能下单。
increment 是个原子操作。

综上所述：

方案三满足秒杀、高并发抢购等热点商品的处理，真正减扣库存和下单可以异步执行。在并发情况不高，平常商品或者正常购买流程，可以采用方案一数据库乐观锁的处理，或者对方案三进行重新设计，设计成支持单订单多商品即可，但复杂性提高，同时redis和mysql数据一致性需要定期检查。

订单时效问题
超过订单有效时间，订单取消，可利用MQ或其他方案回退库存。

设置定时检查
Spring task 的cron表达式定时任务
MQ消息延时队列

订单与库存涉及的几个重要知识

TCC 模型：Try/Confirm/Cancel：不使用强一致性的处理方案，最终一致性即可，下单减库存，成功后生成订单数据，如果此时由于超时导致库存扣成功但是返回失败，则通过定时任务检查进行数据恢复，如果本条数据执行次数超过某个限制，人工回滚。还库存也是这样。
幂等性：分布式高并发系统如何保证对外接口的幂等性，记录库存流水是实现库存回滚，支持幂等性的一个解决方案，订单号+skuCode为唯一主键（该表修改频次高，少建索引）
乐观锁：where stock + num>0
消息队列：实现分布式事务和异步处理(提升响应速度)
redis：限制请求频次，高并发解决方案，提升响应速度
分布式锁：防止重复提交，防止高并发，强制串行化
分布式事务：最终一致性，同步处理(Dubbo)/异步处理（MQ）修改 + 补偿机制

写在最后的话

大家看完有什么不懂的可以在下方留言讨论，也可以私信问我一般看到后我都会回复的。也欢迎大家关注我的公众号：前程有光，金三银四跳槽面试季，整理了1000多道将近500多页pdf文档的Java面试题资料，文章都会在里面更新，整理的资料也会放在里面。最后觉得文章对你有帮助的话记得点个赞哦，点点关注不迷路，每天都有新鲜的干货分享！

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

实在是秒啊，我还从来没见过把Spring之AOP讲的这么通俗

发表于 2020-07-15

Spring之AOP

什么是AOP？

AOP 为 Aspect Oriented Programming 的缩写，意思为面向切面编程，是通过预编译方式和运行期动态代理实现程序功能的统一维护的一种技术。

目的：
利用AOP可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。

作用及其优势

作用：在程序运行期间，在不修改源码的情况下对方法进行功能增强

优势：减少重复代码，提高开发效率，并且便于维护

AOP 的底层实现

AOP 的底层是通过 Spring 提供的的动态代理技术实现的。在运行期间，Spring通过动态代理技术动态的生成代理对象，代理对象方法执行时进行增强功能的介入，在去调用目标对象的方法，从而完成功能的增强。

AOP 的动态代理技术

JDK 代理 : 基于接口的动态代理技术

cglib 代理：基于父类的动态代理技术

JDK 的动态代理

①目标类接口

1
2
3

复制代码public interface TargetInterface {
   public void method();
}

②目标类

复制代码public class Target implements TargetInterface {
    @Override
    public void method() {
        System.out.println("Target running....");
    }
}

③动态代理代码

复制代码Target target = new Target(); //创建目标对象
//创建代理对象
TargetInterface proxy = (TargetInterface) Proxy.newProxyInstance(target.getClass()
.getClassLoader(),target.getClass().getInterfaces(),new InvocationHandler() {
            @Override
            public Object invoke(Object proxy, Method method, Object[] args) 
            throws Throwable {
                System.out.println("前置增强代码...");
                Object invoke = method.invoke(target, args);
                System.out.println("后置增强代码...");
                return invoke;
            }
        }
);

④ 调用代理对象的方法测试

1 2	复制代码// 测试,当调用接口的任何方法时，代理对象的代码都无需修改 proxy.method();

cglib 的动态代理

①目标类

复制代码public class Target {
  public void method() {
      System.out.println("Target running....");
  }
}

②动态代理代码

复制代码Target target = new Target(); //创建目标对象
Enhancer enhancer = new Enhancer();   //创建增强器
enhancer.setSuperclass(Target.class); //设置父类
enhancer.setCallback(new MethodInterceptor() { //设置回调
    @Override
    public Object intercept(Object o, Method method, Object[] objects, 
    MethodProxy methodProxy) throws Throwable {
        System.out.println("前置代码增强....");
        Object invoke = method.invoke(target, objects);
        System.out.println("后置代码增强....");
        return invoke;
    }
});
Target proxy = (Target) enhancer.create(); //创建代理对象

③调用代理对象的方法测试

1 2	复制代码//测试,当调用接口的任何方法时，代理对象的代码都无需修改 proxy.method();

基于XML配置文件的AOP开发

①导入 AOP 相关坐标

复制代码    <!--导入spring的context坐标，context依赖aop-->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>5.2.5.RELEASE</version>
        </dependency>
        <!--spring测试的依赖-->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-test</artifactId>
            <version>5.2.5.RELEASE</version>
        </dependency>

        <!-- aspectj的织入 -->
        <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjweaver</artifactId>
            <version>1.9.2</version>
        </dependency>

②创建目标接口和目标类（内部有切点）

复制代码public interface TestService {

    public void save();
}


public class TestServiceImpl implements TestService {


    public void save() {
        System.out.println("save方法runnning......");
    }
}

③创建切面类（内部有增强方法）

复制代码public class Advice {

    //前置增强的通知
    public void before(){

        System.out.println("前置增强......");

    }
    }

④将目标类和切面类的对象创建权交给 spring

复制代码  <!--配置目标类-->
  <bean id="testService" class="com.duanping.service.impl.TestServiceImpl"></bean>

  <!--配置切面类-->
  <bean id="advice" class="com.duanping.advices.Advice"></bean>

⑤在 applicationContext.xml 中配置织入关系

导入aop命名空间

复制代码<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd
       http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd

        ">

配置切点表达式和前置增强的织入关系

复制代码   <!--配置织入： 告诉spring框架 哪些方法（切点）需要进行哪些增强（前置、后置....）  -->
   <aop:config>

       <!-- 声明切面   引入advice的bean作为切面对象-->
       <aop:aspect  ref="advice">
           <!--切面： 通知+切点    配置对切点的方法进行前置增强-->
           <aop:before method="before" pointcut="execution(public void com.duanping.service.impl.TestServiceImpl.save())"></aop:before>
   </aop:aspect>
</aop:config>

⑥测试代码

复制代码@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("classpath:applicationContext.xml")
public class AopTest {

    @Autowired
    private TestService testService;

    @Test
    public void test1(){

        testService.save();
    }
}

⑦测试结果

XML 配置 AOP 详解

1) 切点表达式的写法

表达式语法：

1	复制代码execution([修饰符] 返回值类型包名.类名.方法名(参数))

访问修饰符可以省略

返回值类型、包名、类名、方法名可以使用星号* 代表任意

包名与类名之间一个点 . 代表当前包下的类，两个点 … 表示当前包及其子包下的类

参数列表可以使用两个点 … 表示任意个数，任意类型的参数列表

例如：

复制代码execution(public void com.itheima.aop.Target.method())	
execution(void com.itheima.aop.Target.*(..))
execution(* com.itheima.aop.*.*(..))
execution(* com.itheima.aop..*.*(..))
execution(* *..*.*(..))

2) 通知的类型

通知的配置语法：

1	复制代码<aop:通知类型 method=“切面类中方法名” pointcut=“切点表达式"></aop:通知类型>

3) 切点表达式的抽取

当多个增强的切点表达式相同时，可以将切点表达式进行抽取，在增强中使用 pointcut-ref 属性代替 pointcut 属性来引用抽取后的切点表达式。

复制代码            <!--对切点的抽取-->
            <aop:pointcut id="point" expression="execution(* com.duanping.service.impl.*.*(..))"/>


            <aop:before method="before" pointcut-ref="point"></aop:before>

基于注解的 AOP 开发

在配置文件中开启组件扫描和 AOP 的自动代理

复制代码<!--组件扫描-->
<context:component-scan base-package="com.itheima.aop"/>

<!--aop的自动代理-->
<aop:aspectj-autoproxy></aop:aspectj-autoproxy>

注解配置 AOP 详解

1) 注解通知的类型

通知的配置语法：@通知注解(“切点表达式”)

2) 切点表达式的抽取

同 xml配置
aop 一样，我们可以将切点表达式抽取。抽取方式是在切面内定义方法，在该方法上使用@Pointcut注解定义切点表达式，然后在在增强注解中进行引用

复制代码    @Pointcut("execution(* com.duanping..*.*(..))")
    public void pointcut(){}

    //前置增强的通知
    @Before("pointcut()")
    public void before(){

        System.out.println("前置增强......");

    }

知识要点

注解aop开发步骤
①使用@Aspect标注切面类

②使用@通知注解标注通知方法

③在配置文件中配置aop自动代理aop:aspectj-autoproxy/\

最后

大家看完有什么不懂的可以在下方留言讨论，也可以关注我私信问我，我看到后都会回答的。也可以关注我的公众号：前程有光，金三银四跳槽面试季，整理了1000多道将近500多页pdf文档的Java面试题资料，文章都会在里面更新，整理的资料也会放在里面。谢谢你的观看，觉得对你有帮助的话可以专注我点个赞支持一下！

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

CGLIB动态代理实现与原理（一）

发表于 2020-07-14

一、实现原理

利用ASM开源包，将真实对象类的class文件加载进来，通过修改字节码生成其子类，覆盖父类相应的方法。

备注：ASM是直接操作字节码的框架。

二、实现方式

1）定义拦截处理器。实现MethodInterceptor接口，覆写intercept方法用于拦截处理。
2）生成动态代理类。修改被代理对象的class文件字节码生成子类。

复制代码    <dependency>
      <groupId>cglib</groupId>
      <artifactId>cglib-nodep</artifactId>
      <version>3.3.0</version>
      <scope>compile</scope>
    </dependency>

复制代码package com.java24k.example.target;

/**
 * @Description: 真实主题即被代理对象
 * @Author zhoufeng
 * @Date 2020/7/13 2:34
 * @version: V1.0
 */
public class TargetClass {

    public void targetInfo(){
        System.out.println("打印目标类信息");
     }
}

复制代码package com.java24k.example.interceptor;

import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;

import java.lang.reflect.Method;

/**
 * @Description: 代理拦截处理器
 * @Author zhoufeng
 * @Date 2020/7/13 2:30
 * @version: V1.0
 */
public class MyInterceptor implements MethodInterceptor {

    @Override
    public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
        System.out.println("------插入前置通知代码-------------");
        // 此处一定要使用proxy的invokeSuper方法来调用目标类的方法
        methodProxy.invokeSuper(o, objects);
        System.out.println("------插入后置处理代码-------------");
        return null;
    }
}

复制代码package com.java24k.example.test;

import com.java24k.example.interceptor.MyInterceptor;
import com.java24k.example.target.TargetClass;
import net.sf.cglib.proxy.Enhancer;

/**
 * @Description: 生成cglib代理测试类
 * @Author zhoufeng
 * @Date 2020/7/13 2:41
 * @version: V1.0
 */
public class CglibProxyTest {

    public static void main(String[] args) {
        Enhancer enhancer = new Enhancer();
        // 设置目标类
        enhancer.setSuperclass(TargetClass.class);
        // 设置拦截器对象
        enhancer.setCallback(new MyInterceptor());
        // 创建子类 即代理
        TargetClass targetClassProxy = (TargetClass) enhancer.create();
        targetClassProxy.targetInfo();
    }
}

复制代码------插入前置通知代码-------------
打印目标类信息
------插入后置处理代码-------------

Process finished with exit code 0

三、FastClass机制

在JDK动态代理中，调用目标对象的方法使用的是反射，而在CGLIB动态代理中使用的是FastClass机制。

FastClass使用：动态生成一个继承FastClass的类，并向类中写入委托对象，直接调用委托对象的方法。
FastClass逻辑：在继承FastClass的动态类中，根据方法签名(方法名字+方法参数)得到方法索引，根据方法索引调用目标对象方法。
FastClass优点：FastClass用于代替Java反射，避免了反射造成调用慢的问题。

第二节和第三节我们将剖析CGLIB生成动态代理源码和FastClass源码。

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

深度分析：java8的新特性lambda和stream流，看

发表于 2020-07-14

lambda表达式

1.1 什么是lambda

以java为例，可以对一个java变量赋一个值，比如int a = 1，而对于一个方法，一块代码也是赋予给一个变量的，对于这块代码，或者说被赋给变量的函数，就是一个lambda表达式

复制代码//为变量赋值
int a = 1;

//将代码块赋值给变量
var = public void fun(int x){
	x+1;
}

//可以简化
var = (x)->x+1;

1.2 java为什么要引入lambda

lambda是为函数式编程服务的
编程语言共性之——什么是函数式编程？
函数式编程是一种编程范式，也就是如何编写程序的方法论，主要思想是把运算过程尽量编写成一系列嵌套的函数调用，FP强调“everything is lambda”，并且强调在逻辑处理中不变性的重要性

OOP强调“everything is object”，以及object之间的消息传递。通过消息传递改变每个Object的内部状态，但是很多情况代码的编写实际上是用不到对象的，比如，对一组数据做加工，先查询，然后聚合，聚合后排序，再join，再排序，再聚合，再转换（map）得到最终的结果。这个过程，用FP的函数就很自然

1	复制代码result = func1(func2(func3...funcN(x))))

java为了在原先oop的思想上增加函数式编程的使用，在java8上增加了lambda函数的新特性

除此之外，lambda表达式的引入还使得代码更为简洁，可以避免生成过多的污染环境的无用实现类（下面说）

1.3 如何使用lambda表达式

lambda表达式的引入可以避免生成过多的污染环境的实现类；
lambda表达式可以被赋值给一个变量，那么这个变量的类型是什么？
在java中，所有的Lambda的类型都是一个接口，而Lambda表达式本身，需要是这个接口的实现，这个接口需要具备三个特征，具备这些特征的接口叫做函数式接口

函数式接口只有一个抽象方法
default方法为默认实现，不计入抽象方法
如果接口声明了一个覆盖java.lang.Object的全局方法之一的抽象方法，那么它不会计入接口的抽象方法数量中，因为接口的任何实现都将具有java.lang.Object或其他地方的实现
如何使用lambda表达式
比如Comparator接口就是一个函数式接口，所以他可以使用lambda表达式，在之前使用comparator对一个list排序是下面这样的

复制代码List<Integer> list = new ArrayList<>();
Collections.sort(list, new Comparator<Integer>() {
    @Override
    public int compare(Integer o1, Integer o2) {
        return o1-o2;
    }
});

可以看到上面实际真正有用的是return o1 - o2，上面的代码使用lambda表达式写如下

1	复制代码Collections.sort(list, ((o1, o2) -> o1-o2));

Lambda 表达式的基础语法：Lambda 操作符->将 Lambda 表达式拆分成两部分：
左侧：Lambda 表达式的参数列表；
右侧：Lambda 表达式中所需执行的功能，即 Lambda 体；

复制代码语法格式一：无参数，无返回值
() -> System.out.println("Hello Lambda!");

语法格式二：有一个参数，并且无返回值
(x) -> System.out.println(x)

语法格式三：若只有一个参数，小括号可以省略不写
x -> System.out.println(x)

语法格式四：有两个以上的参数，有返回值，并且 Lambda 体中有多条语句
Comparator<Integer> com = (x, y) -> {
System.out.println("函数式接口");
return Integer.compare(x, y);
};

语法格式五：若 Lambda 体中只有一条语句， return 和 大括号都可以省略不写
Comparator<Integer> com = (x, y) -> Integer.compare(x, y);

1.4 lambda表达式方法引用，构造器引用和数组引用

方法引用
若 Lambda 体中的功能，已经有方法提供了实现，可以使用方法引用

1
2
3

复制代码对象的引用 :: 实例方法名
类名 :: 静态方法名
类名 :: 实例方法名

①方法引用所引用的方法的参数列表与返回值类型，需要与函数式接口中抽象方法的参数列表和返回值类型保持一致！
②若Lambda 的参数列表的第一个参数，是实例方法的调用者，第二个参数(或无参)是实例方法的参数时，格式： ClassName::MethodName

复制代码//对象的引用 :: 实例方法名
@Test
public void test1(){
        // 之前我们是这样写的
    Employee emp = new Employee(101, "张三", 18, 9999);
    Supplier<String> sup = () -> emp.getName();
    System.out.println(sup.get());  

    System.out.println("----------------------------------");   
        // 现在我们是这样写的
    Supplier<String> sup2 = emp::getName;
    System.out.println(sup2.get());
}

//类名 :: 静态方法名
@Test
public void test2(){
    Comparator<Integer> com = (x, y) -> Integer.compare(x, y);  
    System.out.println("-------------------------------------");     
    Comparator<Integer> com2 = Integer::compare;
}

//类名 :: 实例方法名
@Test
public void test3(){
    BiPredicate<String, String> bp = (x, y) -> x.equals(y);
    System.out.println(bp.test("abcde", "abcde"));
        
    System.out.println("-----------------------------------------");
        
    BiPredicate<String, String> bp2 = String::equals;
    System.out.println(bp2.test("abc", "abc"));

}

构造器引用

对于person类，有两个构造器

复制代码class Person {
    String firstName;
    String lastName;

    Person() {}

    Person(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }
}

现在有一个工厂接口用来生成person类

复制代码// Person 工厂
interface PersonFactory<P extends Person> {
    P create(String firstName, String lastName);
}

我们可以通过 :: 关键字来引用 Person 类的构造器，来代替手动去实现这个工厂接口：

1
2
3

复制代码// 直接引用 Person 构造器
PersonFactory<Person> personFactory = Person::new;
Person person = personFactory.create("Peter", "Parker");

Person::new 这段代码，能够直接引用 Person 类的构造器。然后 Java 编译器能够根据上下文选中正确的构造器去实现 PersonFactory.create 方法

2.1 什么是Stream

Java 8引入了全新的Stream API，这里的Stream和I/O流不同，Java 8 中的 Stream 是对集合（Collection）对象功能的增强，它专注于对集合对象进行各种非常便利、高效的聚合操作，或者大批量数据操作，Stream API 借助于同样新出现的 Lambda 表达式，极大的提高编程效率和程序可读性

Stream 就如同一个迭代器（Iterator），单向，不可往复，数据只能遍历一次，遍历过一次后即用尽了，就好比流水从面前流过，一去不复返

复制代码List<String> myList =
    Arrays.asList("a1", "a2", "b1", "c2", "c1");

myList
    .stream() // 创建流
    .filter(s -> s.startsWith("c")) // 执行过滤，过滤出以 c 为前缀的字符串
    .map(String::toUpperCase) // 转换成大写
    .sorted() // 排序
    .forEach(System.out::println); // for 循环打印

①：中间操作会再次返回一个流，所以，我们可以链接多个中间操作，注意这里是不用加分号的。上图中的filter 过滤，map 对象转换，sorted 排序，就属于中间操作。
②：终端操作是对流操作的一个结束动作，一般返回 void 或者一个非流的结果。上图中的 forEach循环 就是一个终止操作

上面是Stream的简单实用，可以看出它也是函数式编程，更多的表达了业务逻辑

2.2 常用api

创建Stream

1. Arrays.stream()

当在日常编程中面对的是一个数组，可以使用Arrays.stream()方法来使用Stream

1 2	复制代码Integer[] array = new Integer[]{3,4,8,16,19,27,23,99,76,232,33,96}; long count = Arrays.stream(array).filter(i->i>20).count();

2. Stream.of()

当面对数组时除了可以使用Arrays.stream()方法外，还可以使用Stream将需要的数组转成Stream。这个方法不但支持传入数组，将数组转成Stream，也支持传入多个参数，将参数最终转成Stream

复制代码Integer[] array = new Integer[]{3,4,8,16,19,27,23,99,76,232,33,96};
long count = Stream.of(array).filter(i->i>20).count();
long sum = Stream.of(12,77,59,3,654).filter(i->i>20).mapToInt(Integer::intValue).sum();
System.out.println("count："+count+",sum:"+sum);

3. Collection.stream()

这个就是最常见的Stream了。因为Collection是Java中集合接口的父接口，Java中的集合都继承或实现了此接口。所以Java中的集合都可以使用此方法来创建一个Stream

复制代码List<Integer> numbers = new ArrayList<>();
numbers.add(3);
numbers.add(4);
numbers.add(8);
numbers.add(16);   
numbers.stream().forEach(number->{
    System.out.println(number);
});

4.filter

这是一个Stream的过滤转换，此方法会生成一个新的流，其中包含符合某个特定条件的所有元素，filter接受一个函数作为参数，该函数用Lambda表达式表示

复制代码List<Integer> integerList = Lists.newArrayList();
integerList.add(15);
integerList.add(32);
integerList.add(5);
integerList.add(232);
integerList.add(56);
List<Integer> after = integerList.stream()
&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;.filter(i->i>50)
&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;.collect(Collectors.toList());
System.out.println(after);//232，56

5.map

map方法指对一个流中的值进行某种形式的转换。需要传递给它一个转换的函数作为参数

复制代码List<Integer> integerList = Lists.newArrayList();
integerList.add(15);
integerList.add(32);
integerList.add(5);
integerList.add(232);
integerList.add(56);
//将Integer类型转换成String类型
List<String> afterString = integerList.stream()
&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;.map(i->String.valueOf(i)).collect(Collectors.toList());

6.flatMap

将多个Stream连接成一个Stream，这时候不是用新值取代Stream的值，与map有所区别，这是重新生成一个Stream对象取而代之

复制代码List<String> words = new ArrayList<String>();
words.add("your");
words.add("name");


public static Stream<Character> characterStream(String s){  
    List<Character> result = new ArrayList<>();  
    for (char c : s.toCharArray()) 
        result.add(c);
    return result.stream();  
}
  
Stream<Stream<Character>> result = words.map(w -> characterStream(w));  
//[['y', 'o', 'u', 'r'], ['n', 'a', 'm', 'e']]
Stream<Character> letters = words.flatMap(w -> characterStream(w));
//['y', 'o', 'u', 'r', 'n', 'a', 'm', 'e']

7.limit方法和skip方法

limit(n)方法会返回一个包含n个元素的新的流（若总长小于n则返回原始流）
skip(n)方法正好相反，它会丢弃掉前面的n个元素
用limit和skip方法一起使用就可以实现日常的分页功能：

1
2
3

复制代码List<Integer> pageList = myList.stream()
&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;.skip(pageNumber*pageSize)
&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;.limit(pageSize).collect(Collectors.toList());

8.distinct方法和sorted方法

distinct方法会根据原始流中的元素返回一个具有相同顺序、去除了重复元素的流，这个操作显然是需要记住之前读取的元素。

复制代码List<Integer> myTestList = Lists.newArrayList();
myTestList.add(10);
myTestList.add(39);
myTestList.add(10);
myTestList.add(78);
myTestList.add(10);
List<Integer> distinctList = myTestList.stream()
&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;.distinct().collect(Collectors.toList());
System.out.println("distinctList："+distinctList);
运行结果：
distinctList：[10, 39, 78]

sorted方法是需要遍历整个流的，并在产生任何元素之前对它进行排序。因为有可能排序后集合的第一个元素会在未排序集合的最后一位。

复制代码List<Integer> myTestList = Lists.newArrayList();
myTestList.add(39);
myTestList.add(78);
myTestList.add(10);
myTestList.add(22);
myTestList.add(56);
List<Integer> sortList = myTestList.stream()
&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;.sorted(Integer::compareTo).collect(Collectors.toList());
System.out.println("sortList："+sortList);
运行结果：
sortList：[10, 22, 39, 56, 78]

9.Collect

collect在流中生成列表，map，等常用的数据结构

复制代码将一个流收集到一个List中，只需要这样写就可以。
List<Integer> thereList = hereList.stream().collect(Collectors.toList());

收集到Set中可以这样用
Set<Integer> thereSet = hereList.stream().collect(Collectors.toSet());

收集到Set时，控制Set的类型，可以这样。
TreeSet<Integer> treeSet = hereList.stream()
&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;.collect(Collectors.toCollection(TreeSet::new));

10.聚合操作

聚合是指将流汇聚为一个值，以便在程序中使用。聚合方法都是终止操作，聚合方法包括sum，count，max，min

1	复制代码long sum = Stream.of(12,77,59,3,654).filter(i->i>20).mapToInt(Integer::intValue).sum();

复制代码findFirst方法返回非空集合中的第一个值，它通常与filter方法结合起来使用
Integer first = hearList.stream().filter(i->i>100).findFirst().get();

findAny方法可以在集合中只要找到任何一个所匹配的元素，就返回，此方法在对流并行执行时十分有效
Integer anyItem = hearList.parallelStream().filter(i->i>100).findAny().get();

11.分组

对具有相同特性的值进行分组是一个很常见的功能

复制代码将一个Room对象集合按照高度分组。

List<Room> roomList = Lists.newArrayList(
new Room(11,23,56),
new Room(11,84,48),
new Room(22,46,112),
new Room(22,75,62),
new Room(22,56,75),
new Room(33,92,224));

Map<Integer,List<Room>> groupMap = roomList.stream().collect(Collectors.groupingBy(Room::getHigh));
System.out.println("groupMap："+groupMap);

2.3 Stream流的处理顺序

Stream流的中间操作具有延迟性，当且仅当存在终端操作时，中间操作才会被执行

复制代码Stream.of("d2", "a2", "b1", "b3", "c")
    .filter(s -> {
        System.out.println("filter: " + s);
        return true;
    });

执行此代码段时，不会打印任何内容，对上面的代码添加 forEach终端操作，就有打印内容了

复制代码Stream.of("d2", "a2", "b1", "b3", "c")
    .filter(s -> {
        System.out.println("filter: " + s);
        return true;
    })
    .forEach(s -> System.out.println("forEach: " + s));

复制代码filter:  d2
forEach: d2
filter:  a2
forEach: a2
filter:  b1
forEach: b1
filter:  b3
forEach: b3
filter:  c
forEach: c

但是可以看到输出结果并不是先将所有filter操作的打印语句打印出来；事实上，输出的结果却是随着链条垂直移动的，比如说，当 Stream 开始处理 d2 元素时，它实际上会在执行完 filter 操作后，再执行 forEach 操作，接着才会处理第二个元素

原因是出于性能的考虑。这样设计可以减少对每个元素的实际操作数，比如下面操作

复制代码Stream.of("d2", "a2", "b1", "b3", "c")
    .map(s -> {
        System.out.println("map: " + s);
        return s.toUpperCase(); // 转大写
    })
    .anyMatch(s -> {
        System.out.println("anyMatch: " + s);
        return s.startsWith("A"); // 过滤出以 A 为前缀的元素
    });

// map:      d2
// anyMatch: D2
// map:      a2
// anyMatch: A2

终端操作 anyMatch()表示任何一个元素以 A 为前缀，返回为 true，就停止循环。所以它会从 d2 开始匹配，接着循环到 a2 的时候，返回为 true ，于是停止循环。

由于数据流的链式调用是垂直执行的，map这里只需要执行两次。相对于水平执行来说，map会执行尽可能少的次数，而不是把所有元素都 map 转换一遍

1	复制代码stream --> filter --> map --> sorted --> collect

2.4 并行流

和迭代器不同的是，Stream 可以并行化操作，迭代器只能命令式地、串行化操作。顾名思义，当使用串行方式去遍历时，每个 item 读完后再读下一个 item；
Stream具有平行处理能力，处理的过程会分而治之，也就是将一个大任务切分成多个小任务，这表示每个任务都是一个操作

1 2	复制代码//parallel方法可以将任意的串行流转换为一个并行流 Stream.of(roomList).parallel();

复制代码List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9);
numbers.parallelStream()
       .forEach(out::println);  
//展示顺序不一定会是1、2、3、4、5、6、7、8、9，而可能是任意的顺序

最后

大家看完有什么不懂的欢迎在下方留言讨论

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

没错，用三方 Github 做授权登录就是这么简单！（OAu

发表于 2020-07-14

本文收录在个人博客：www.chengxy-nds.top，技术资源共享。

上一篇《OAuth2.0 的四种授权方式》文末说过，后续要来一波OAuth2.0实战，耽误了几天今儿终于补上了。

最近在做自己的开源项目（fire），Springboot + vue 的前后端分离框架才搭建完，刚开始做登录功能，做着做着觉得普通账户密码登录太简单了没啥意思，思来想去为显得逼格高一点，决定再加上 GitHub授权和 人脸识别等多种登录方式。

在这里插入图片描述

而GitHub授权登录正好用到了OAuth2.0中最复杂的授权码模式，正好拿我这个案例给大家分享一下OAuth2.0的授权过程，后续项目功能会持续更新。

一、授权流程

在具体做GitHub授权登录之前，咱们再简单回顾一下OAuth2.0授权码模式的授权流程，如果 fire 网站允许用GitHub 账号登录，流程大致如下图。

在这里插入图片描述

用户想用GitHub 账号去登录 fire 网站：

fire 网站先让用户跳转到 GitHub 进行授权，会弹出一个授权框。
用户同意后，GitHub 会根据redirect_uri 重定向回 fire 网站，同时返回一个授权码code。
fire 网站使用授权码和客户端密匙client_secret，向 GitHub 请求令牌token，检验通过返回令牌。
最后fire 网站向GitHub 请求数据，每次调用 GitHub 的 API 都要带上令牌。

二、身份注册

梳理完授权逻辑，接下来我们还有一些准备工作。

要想得到一个网站的OAuth授权，必须要到它的网站进行身份注册，拿到应用的身份识别码 ClientID 和 ClientSecret。

注册传送门 https://github.com/settings/applications/1334665，有几个必填项。

Application name：我们的应用名；
Homepage URL：应用主页链接；
Authorization callback URL：这个是github 回调我们项目的地址，用来获取授权码和令牌。

提交后会看到就可以看到客户端ClientID 和客户端密匙ClientSecret，到这我们的准备工作就完事了。

在这里插入图片描述

三、授权开发

1、获取授权码

为了更好的看效果，获取授权码我处理的比较粗暴，直接在JS里拼装好了授权链接，但实际工作开发中一定要考虑到安全问题。

1
2
3

复制代码https://github.com/login/oauth/authorize?
client_id=ad41c05c211421c659db&
redirect_uri=http://47.93.6.5:8080/authorize/redirect

前端 vue 的逻辑也非常简单，只需要 window.location.href 重定向一下。

复制代码<script>
export default {
  methods: {
    loginByGithub: function () {
      window.location.href = 'https://github.com/login/oauth/authorize?client_id=ad41c05c211421c659db&redirect_uri=http://47.93.6.5:8080/authorize/redirect'
    }
  }
}
</script>

请求后会提示让我们授权，同意授权后会重定向到authorize/redirect，并携带授权码code；如果之前已经同意过，会跳过这一步直接回调。

在这里插入图片描述

2、获取令牌

授权后紧接着就要回调 fire 网站接口，拿到授权码以后拼装获取令牌 access_token的请求链接，这时会用到客户端密匙client_secret。

复制代码https://github.com/login/oauth/access_token? 
    client_id=${clientID}& 
    client_secret=${clientSecret}& 
    code=${requestToken}

access_token 会作为请求响应返回，结果是个串字符，需要我们截取一下。

1	复制代码access_token=4dc43c2f43b773c327f97acf5dd66b147db9259c&scope=&token_type=bearer

有了令牌以后开始获取用户信息，在 API 中要带上access_token。

1	复制代码https://api.github.com/user?access_token=4dc43c2f43b773c327f97acf5dd66b147db9259c

返回的用户信息是 JSON 数据格式，如果想把数据传递给前端，可以通过 url 重定向到前端页面，将数据以参数的方式传递。

复制代码{
    "login": "chengxy-nds",
    "id": 12745094,
    "node_id": "",
    "avatar_url": "https://avatars3.githubusercontent.com/u/12745094?v=4",
    "gravatar_id": "",
    "url": "https://api.github.com/users/chengxy-nds",
    "html_url": "https://github.com/chengxy-nds",
    "followers_url": "https://api.github.com/users/chengxy-nds/followers",
    "following_url": "https://api.github.com/users/chengxy-nds/following{/other_user}",
    "gists_url": "https://api.github.com/users/chengxy-nds/gists{/gist_id}",
    "starred_url": "https://api.github.com/users/chengxy-nds/starred{/owner}{/repo}",
    "subscriptions_url": "https://api.github.com/users/chengxy-nds/subscriptions",
    "organizations_url": "https://api.github.com/users/chengxy-nds/orgs",
    "repos_url": "https://api.github.com/users/chengxy-nds/repos",
    "events_url": "https://api.github.com/users/chengxy-nds/events{/privacy}",
    "received_events_url": "https://api.github.com/users/chengxy-nds/received_events",
    "type": "",
    "site_admin": false,
    "name": "程序员内点事",
    "company": null,
    "blog": "",
    "location": null,
    "email": "",
    "hireable": null,
    "bio": null,
    "twitter_username": null,
    "public_repos": 7,
    "public_gists": 0,
    "followers": 14,
    "following": 0,
    "created_at": "2015-06-04T09:22:44Z",
    "updated_at": "2020-07-13T06:08:57Z"
}

下边是 GitHub 回调我们 fire网站后端处理流程的部分代码，写的比较糙，后续继续优化吧！

复制代码/**
     * @param code
     * @author xiaofu
     * @description 授权回调
     * @date 2020/7/10 15:42
     */
   @RequestMapping("/authorize/redirect")
    public ModelAndView authorize(@NotEmpty String code) {

        log.info("授权码code: {}", code);

        /**
         * 重新到前端主页
         */
        String redirectHome = "http://47.93.6.5/home";

        try {
            /**
             * 1、拼装获取accessToken url
             */
            String accessTokenUrl = gitHubProperties.getAccesstokenUrl()
                    .replace("clientId", gitHubProperties.getClientId())
                    .replace("clientSecret", gitHubProperties.getClientSecret())
                    .replace("authorize_code", code);

            /**
             * 返回结果中直接返回token
             */
            String result = OkHttpClientUtil.sendByGetUrl(accessTokenUrl);
            log.info(" 请求 token 结果：{}", result);

            String accessToken = null;
            Pattern p = Pattern.compile("=(\\w+)&");
            Matcher m = p.matcher(result);
            while (m.find()) {
                accessToken = m.group(1);
                log.info("令牌token：{}", m.group(1));
                break;
            }

            /**
             * 成功获取token后，开始请求用户信息
             */
            String userInfoUrl = gitHubProperties.getUserUrl().replace("accessToken", accessToken);

            String userResult = OkHttpClientUtil.sendByGetUrl(userInfoUrl);

            log.info("用户信息：{}", userResult);

            UserInfo userInfo = JSON.parseObject(userResult, UserInfo.class);

            redirectHome += "?name=" + userInfo.getName();

        } catch (Exception e) {
            log.error("授权回调异常={}", e);
        }
        return new ModelAndView(new RedirectView(redirectHome));
    }

最后我们动图看一下整体的授权流程，由于GitHub的访问速度比较慢，偶尔会有请求超时的现象。

在这里插入图片描述

线上预览地址：http://47.93.6.5/login ，欢迎体验~

项目 GitHub 地址：https://github.com/chengxy-nds/fire.git

总结

从整个GitHub授权登录的过程来看，OAuth2.0的授权码模式还是比较简单的，搞懂了一个GitHub的登录，像微信、围脖其他三方登录也就都会了，完全是大同小异的东西，感兴趣的同学可以试一试。

原创不易，燃烧秀发输出内容，如果有一丢丢收获，点个赞鼓励一下吧！

整理了几百本各类技术电子书，送给小伙伴们。关注公号回复【666】自行领取。和一些小伙伴们建了一个技术交流群，一起探讨技术、分享技术资料，旨在共同学习进步，如果感兴趣就扫码加入我们吧！

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

Android过渡动画，发现掘金小秘密

发表于 2020-07-14

不知道大家有没有发现，Android版的掘金有下面这个小小动画：点击作者头像跳转到作者的详情页，而作者头像会从当前界面通过动画过渡到详情页界面。

**
知识贫乏限制了我的视野，真心想不到这怎么实现的？

最近在写动画方面文章时候，从网上找到了答案：「Activity过渡动画中的共享元素过渡」。

本文的初衷，是和大家一起扫盲，如果对你有用，「欢迎点赞」，让更多的小伙伴多学点知识。小小的动画，隐藏着巨大的知识点；怪不得面试造火箭，工作拧螺丝，这是知识储备，虽然可能一辈子也用不上。

【「系列好文推荐」】

Android属性动画,看完这篇够用了吧

Android矢量图动画：每人送一辆掘金牌小黄车

一、Activity切换过渡动画

Activity过渡动画包含「进入过渡」和「退出过渡」、「共享元素过渡」三个动画，它们同样仅支持Android 5.0+版本。

一)、共享元素过渡动画

共享元素过渡指的两个Activity共享的视图如何在两个Activity之间进行过渡。例如上面的Gif图，共享视图就是ImageView。

共享元素也分一个元素和多个元素。

定义共享元素过渡效果「步骤」如下：

在两个Activity定义两个相同类型的View；
给两个View设置相同的transitionName属性；
通过ActivityOptions.makeSceneTransitionAnimation()函数生成Bundle对象；
startActivity()函数传递bundle对象。

「栗子讲解，清晰易懂：」

分别在activity_first.xml和activity_second.xml布局文件定义ImageView组件，并将transitionName属性设为activityTransform。

复制代码<!--activity_first.xml文件内容-->

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="@color/white"
    android:orientation="vertical">

    <ImageView
        android:id="@+id/ivImage"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:src="@mipmap/ic_one"
        android:transitionName="activityTransform" />

    <TextView
        android:id="@+id/tvText"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_marginTop="10dp"
        android:gravity="center"
        android:text="我是第一个Activity"
        android:textColor="@color/c_333"
        android:textSize="18sp" />
</LinearLayout>

<!--activity_second.xml文件内容-->
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <ImageView
        android:id="@+id/ivImage"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_alignParentBottom="true"
        android:adjustViewBounds="true"
        android:src="@mipmap/ic_one"
        android:transitionName="activityTransform" />

    <TextView
        android:id="@+id/tvText"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_above="@id/ivImage"
        android:layout_marginBottom="10dp"
        android:gravity="center"
        android:text="我是第2个Activity"
        android:textColor="@color/c_333"
        android:textSize="18sp" />
</RelativeLayout>

「预览图」

activityTransform属性也可以通过代码设置。

1
2
3

复制代码if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    ivImage.transitionName="activityTransform"
}

在FirstActivity中给ImageView设置点击事件，跳转到第二个Activity。

复制代码ivImage.setOnClickListener {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {//判断Android版本
        val bundle =
            ActivityOptions.makeSceneTransitionAnimation(this, ivImage, "activityTransform")
                .toBundle()
        startActivity(Intent(this, SecondActivity::class.java), bundle)
    } else {
        startActivity(Intent(this, SecondActivity::class.java))
    }
}

代码中，先判断当前Android版本是否大于等于5.0，大于或等于Android 5.0的话就设置共享元素动画,小于5.0 就正常启动第二个Activity。

通过ActivityOptions.makeSceneTransitionAnimation()创建启动Activity过渡的一些参数，makeSceneTransitionAnimation()函数第一个参数为Activity对象;第二个参数为共享元素组件，这里设置为id是ivImage的ImageView视图；第三个参数为transitionName属性的值，这里是activityTransform。在调用AcivityOptions对象toBundle函数，包装成Bundle对象。

「效果图：」

「多个共享元素过渡」

多个共享元素过渡也很简单，只需要调用makeSceneTransitionAnimation()函数的另外一个重载函数即可。

在前面XML布局的基础上，给TextView增加transitionName属性:textTransform。

复制代码<!--activity_first.xml文件内容-->
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="@color/white"
    android:orientation="vertical">

    <ImageView
        android:id="@+id/ivImage"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:src="@mipmap/ic_one"
        android:transitionName="activityTransform" />

    <TextView
        android:id="@+id/tvText"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_marginTop="10dp"
        android:gravity="center"
        android:transitionName="textTransform"
        android:text="我是第一个Activity"
        android:textColor="@color/c_333"
        android:textSize="18sp" />
</LinearLayout>

<!--activity_second.xml文件内容-->
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <ImageView
        android:id="@+id/ivSecondImage"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_alignParentBottom="true"
        android:adjustViewBounds="true"
        android:src="@mipmap/ic_one"
        android:transitionName="activityTransform" />

    <TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:transitionName="textTransform"
        android:layout_above="@id/ivSecondImage"
        android:layout_marginBottom="10dp"
        android:gravity="center"
        android:text="我是第2个Activity"
        android:textColor="@color/c_333"
        android:textSize="18sp" />
</RelativeLayout>

构建多个Pair对象，并传递给makeSceneTransitionAnimation()函数，启动Activity。

复制代码ivImage.setOnClickListener {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {             
    
    val imagePair=Pair<View,String>(ivImage,"activityTransform")
    val textPair=Pair<View,String>(ivImage,"textTransform")
    
    val bundle =
        ActivityOptions.makeSceneTransitionAnimation(this,
                imagePair,textPair).toBundle()
        
        startActivity(Intent(this, SecondActivity::class.java), bundle) 
    } else {
        startActivity(Intent(this, SecondActivity::class.java))
    }
}

这里主要是通过将共享视图和transitionName属性的值包装到Pair对象，其他操作和一个共享元素的操作步骤并无区别。

「效果图：」

「深坑提醒」

有时从RecyclerView界面进入到详情页，由于详情页加载延迟，可能出现没有效果。例如ImageView从网络加载图片，可能A界面到B界面没效果，B回到A界面有效果。

解决步骤：

在setContentView后添加下面代码，延迟加载过渡动画。

1
2
3

复制代码if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    postponeEnterTransition()
}

在共享元素视图加载完毕，或者图片加载完毕后调用下面代码,开始加载过渡动画。

1
2
3

复制代码if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    startPostponedEnterTransition()
}

例如我是在Glide加载完再调用：

复制代码 Glide.with(mContext)
                    .asBitmap()
                    .load(value?.avatar ?: "")
                    .listener(object : RequestListener<Bitmap> {
                        override fun onResourceReady(resource: Bitmap?, model: Any?, target: Target<Bitmap>?, dataSource: DataSource?, isFirstResource: Boolean): Boolean {
                            animatorCallback?.invoke()//回调开始加载过渡动画
                            return false
                        }

                        override fun onLoadFailed(e: GlideException?, model: Any?, target: Target<Bitmap>?, isFirstResource: Boolean): Boolean {
                            animatorCallback?.invoke()//回调开始加载过渡动画
                            return false
                        }
                    })
                    .apply(RequestOptions.circleCropTransform())
                    .placeholder(R.mipmap.ic_default)
                    .error(R.mipmap.ic_default)
                    .into(authorBinding!!.ivAvatar)

大家也可以考虑下面代码：

复制代码shareElement.viewTreeObserver.addOnPreDrawListener(object : ViewTreeObserver.OnPreDrawListener {
                override fun onPreDraw(): Boolean {
                    shareElement!!.viewTreeObserver.removeOnPreDrawListener(this)
                    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
                        animatorCallback?.invoke()
                    }
                    return true
                }
            })

二)、进入过渡与退出过渡动画

与共享元素相反的，就是Activity进入与退出过渡动画，两个Activity之间在没有共享的视图情况下进行动画切换。下面先看三种动画效果图：「爆炸式效果」和「淡入淡出式效果」、「滑动式效果」。

「爆炸式」：将视图移入场景中心或从中移出；
「滑动式」：将视图从场景的其中一个边缘移入或移出；
「爆炸式」：通过更改视图的不透明度，在场景中添加视图或从中移除视图；

第一个界面采用Fade淡入淡出效果，第二个界面采用了Explode爆炸效果。

前后两个界面都采用了Slide滑入滑出效果。

利用Android现有的过渡框架,实现起来是很简单的，步骤如下：

在Activity的onCreate()方法中调用 setContentView()前设置启用窗口过渡属性;

1	复制代码window.requestFeature(Window.FEATURE_CONTENT_TRANSITIONS)

创建过渡效果对象Slide、Explode、Fade;

1
2
3

复制代码val slide=Slide()
slide.slideEdge=Gravity.START
slide.duration=300//效果时长，一般Activity切换时间很短，不建议设置过长

如果是Slide效果，可以设置slideEdge属性来指定滑动方向，默认是Gravity.BOTTOM。

将过渡效果设置给window相关属性，设置；

复制代码//退出当前界面的过渡动画
window.exitTransition = slide
//进入当前界面的过渡动画
window.enterTransition = slide
//重新进入界面的过渡动画
window.reenterTransition = slide

调用第二个Activity界面，使用过渡效果。

1
2
3

复制代码 startActivity(
        Intent(this, SecondActivity::class.java),
        ActivityOptions.makeSceneTransitionAnimation(this).toBundle())

那么Activity的OnCreate()方法看起来是这样子的。

复制代码    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
            window.requestFeature(Window.FEATURE_CONTENT_TRANSITIONS)
            window.allowEnterTransitionOverlap=false
            Slide().apply {
                duration = 300
                excludeTarget(android.R.id.statusBarBackground, true)
                excludeTarget(android.R.id.navigationBarBackground, true)
            }.also {
                window.exitTransition = it
                window.enterTransition = it
                window.reenterTransition = it
            }
        }
        
        setContentView(R.layout.activity_first)

        ivContent.setOnClickListener {
            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
                startActivity(
                    Intent(this, SecondActivity::class.java),
                    ActivityOptions.makeSceneTransitionAnimation(this).toBundle()
                )
            }
        }
    }

上面代码中调用了excludeTarget()方法将状态栏和导航栏排除在过渡动画效果之外。否则会跟着一起起动画效果，不是很美观。

正常情况，退出与进入过渡动画会有一小段交叉的过程，而window.allowEnterTransitionOverlap=false就是禁止交叉，只有退出过渡动画结束后才会再显示进入过渡动画。

如果第二个Activity在finish掉后，回到第一个Activity界面也想有过渡效果，就不要手动调用finish(),可以调用finishAfterTransition ()方法。

三)、兼容Android 5.0前

如果Android 5.0前也想要有切换动画怎么办？

在res/anim文件夹下创建想要的效果：

复制代码<alpha 
    xmlns:android="http://schemas.android.com/apk/res/android"
        android:interpolator="@interpolator/decelerate_quad"
        android:fromAlpha="0.0"
        android:toAlpha="1.0"
        android:duration="@android:integer/config_longAnimTime" />

在启动Activity后调用overridePendingTransition()方法。

1
2
3

复制代码val intent = Intent(this, TestActivity2::class.java)
startActivity(intent)
overridePendingTransition(R.anim.fade_in, R.anim.fade_out)

overridePendingTransition()方法第一个参数为下一个界面进入动画，第二个参数为当前界面退出动画。

到这里，Activity的切换使用过渡动画基本就结束了。有朋友可能会问，只有Activity切换才能应用过渡效果么？

二、布局变化过渡动画

在上一节要理解一个概念：场景。布局的显示与隐藏可以理解分别为一个场景，过渡动画就是解决场景切换带来的生硬视觉感受。Activity切换过渡动画指在两个Activity之间，而布局变化过渡动画，是指同个Activity之间View的变化过渡动画。

一)、手动创建Scene

手动创建场景的话，需要我们自己创建起始和结束场景，利用现有的过渡效果来达到两个场景的切换。默认情况下，当前界面就是起始场景。

创建起始场景和结束场景的xml布局。起始场景和结束场景需要有相同根元素，例如下面代码id为flConatent的FrameLayout布局。

复制代码<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <TextView
        android:id="@+id/tvText"
        android:text="内容过渡动画"
        android:gravity="center"
        android:textSize="18sp"
        android:layout_width="match_parent"
        android:layout_height="50dp"/>

    <FrameLayout
        android:id="@+id/flContent"
        android:layout_weight="1"
        android:layout_width="match_parent"
        android:layout_height="0dp">
      <include layout="@layout/layout_first_scene"/>
    </FrameLayout>

</LinearLayout>

初始视图，第一个场景,布局layout_first_scene.xml：

复制代码<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">
    <TextView
        android:id="@+id/tvFirst"
        android:textSize="18sp"
        android:layout_marginTop="100dp"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:gravity="center_horizontal|top"
        android:text="感谢大家阅读文章" />
</LinearLayout>

第二个场景,布局layout_second_scene.xml：

复制代码<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <TextView
        android:textSize="18sp"
        android:layout_marginTop="100dp"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:gravity="center_horizontal|top"
        android:text="我是新小梦\n欢迎大家点赞支持一下" />
</LinearLayout>

创建起始场景和结束场景。

1 2	复制代码val firstScene = Scene.getSceneForLayout(flContent, R.layout.layout_first_scene, this) val secondScene = Scene.getSceneForLayout(flContent, R.layout.layout_sencod_scene, this)

默认情况下，过渡动画应用整个场景，如果场景某个View不参加,可以通过过渡效果对象的removeTarget()方法进行移除。

1	复制代码Slide(Gravity.TOP).removeTarget(tvNoJoin)

点击时，进行场景过渡。

复制代码tvText.setOnClickListener {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
        if (isFirst) {
            TransitionManager.go(secondScene, Slide(Gravity.TOP))
        }else{
            TransitionManager.go(firstScene, Slide(Gravity.TOP))
        }
        isFirst=!isFirst
    }
}

TransitionManager.go()第一个参数表示结束场景，第二个参数表示当前场景退出时过渡效果，当前场景就是初始场景。

「效果图：」

二)、系统自动创建Scene

这种情况，我们调用TransitionManager.beginDelayedTransition(sceneRoot)函数时，系统会自动记录当前sceneRoot节点下所有要进行动画的视图作为起始节点，下一帧中再次记录sceneRoot子节点下所有起始场景进行动画状态的视图作为结束场景。这种一般用来改变视图的属性，然后进行动画过渡，如View的宽高。

「栗子」：

定义只有一个正方形的View,通过改变正方形的宽高为原来的2倍，来看看动画效果。

activity_text.xml布局文件，定义id为sceneRoot的根节点，也是场景的根节点。

复制代码<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:id="@+id/sceneRoot"
    android:background="@color/colorPrimary">

    <View
        android:id="@+id/vSquare"
        android:layout_width="100dp"
        android:layout_height="100dp"
        android:layout_centerHorizontal="true"
        android:layout_marginTop="50dp"
        android:background="@color/white" />
</RelativeLayout>

在TestActivity的OnCreate方法中调用下面代码，将正方形的宽高设置200dp。

复制代码vSquare.setOnClickListener {
   TransitionManager.beginDelayedTransition(sceneRoot)
   vSquare.layoutParams.apply {
       width = dp2px(200f, this@TestActivity)
       height = dp2px(200f, this@TestActivity)
   }.also {
       vSquare.layoutParams = it
   }
}

「效果图：」

三、过渡动画效果

上面的动画效果，都是采用系统内置的，那具体有哪些动画效果，或支持自定义么？

过渡效果类都继承自Transition类，Transition类持有场景切动画的相关信息，子类的主要作用是捕获属性值（例如起始值和结束值）和如何演奏动画。从这里也可以看出，过渡动画也是属性动画的一个扩展与应用。

一)、内置过渡动画

系统支持将任何扩展Visibility类的过渡作为进入或退出过渡，内置继承自Visibility的类有Explode、Slide、Fade；支持共享元素过渡的有：

changeScroll 为目标视图滑动添加动画效果
changeBounds 为目标视图布局边界的变化添加动画效果
changeClipBounds 为目标视图裁剪边界的变化添加动画效果
changeTransform 为目标视图缩放和旋转方面的变化添加动画效果
changeImageTransform 为目标图片尺寸和缩放方面的变化添加动画效果

代码示例：

复制代码if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    TransitionSet().apply {
        addTransition(ChangeImageTransform())
        addTransition(ChangeBounds())
        addTransition(Fade(Fade.MODE_IN))
    }.also {
       window.sharedElementEnterTransition=it
    }
}

TransitionSet对象是动画的合集，可以将多个过渡效果组织起来。

也可以通过XML布局来实现,在res/transition文件夹创建``：

复制代码<?xml version="1.0" encoding="utf-8"?>
<transitionSet xmlns:android="http://schemas.android.com/apk/res/android"
    android:duration="300"
    android:transitionOrdering="together">
    <changeImageTransform />
    <changeBounds />
    <fade />
</transitionSet>

transitionSet和fade...等等的一些属性和 Android矢量图动画：每人送一辆掘金牌小黄车文章讲到的一些属性大同小异，这里不再复述。

代码调用：

复制代码if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    TransitionInflater.from(this).inflateTransition(R.transition.transition_set).also {
        window.sharedElementEnterTransition=it
    }
}

「效果图：」

当现有的过渡效果不满足日常需求时，可以通过继承Transition，定制自己的动画特效。

二)、自定义过渡动画

子类继承Transition类，并重写其三个方法。

复制代码class MyTransition : Transition() {
   override fun captureStartValues(transitionValues: TransitionValues?) {}

   override fun captureEndValues(transitionValues: TransitionValues?) {}

   override fun createAnimator(
       sceneRoot: ViewGroup?,
       startValues: TransitionValues?,
       endValues: TransitionValues?
   ): Animator {
       return super.createAnimator(sceneRoot, startValues, endValues)
   }
   
}

captureStartValues()与captureEndValues()方法是必须实现的，捕获动画的起始值和结束值，而createAnimator()方法，是用来创建自定义的动画。

参数TransitionValues可以理解是用来存储View的一些属性值，参数sceneRoot为根视图。

自定义过渡效果感兴趣可以参考：Android自定义Transition动画

好啦，过渡动画就讲到这里~

参考文章：

官网文档

酷炫的Activity切换动画，打造更好的用户体验

我的GitHub

「【码字不易，点个赞，日后好查看】」

本文使用 mdnice 排版**

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

MySQL 三万字精华总结 + 面试100 问，和面试官扯皮

发表于 2020-07-14

写在之前：不建议那种上来就是各种面试题罗列，然后背书式的去记忆，对技术的提升帮助很小，对正经面试也没什么帮助，有点东西的面试官深挖下就懵逼了。

个人建议把面试题看作是费曼学习法中的回顾、简化的环节，准备面试的时候，跟着题目先自己讲给自己听，看看自己会满意吗，不满意就继续学习这个点，如此反复，好的offer离你不远的，奥利给

文章收录在 GitHub JavaKeeper ，N线互联网开发必备技能兵器谱，笔记自取。

一、MySQL架构

和其它数据库相比，MySQL有点与众不同，它的架构可以在多种不同场景中应用并发挥良好作用。主要体现在存储引擎的架构上，插件式的存储引擎架构将查询处理和其它的系统任务以及数据的存储提取相分离。这种架构可以根据业务的需求和实际需要选择合适的存储引擎。

连接层：最上层是一些客户端和连接服务。主要完成一些类似于连接处理、授权认证、及相关的安全方案。在该层上引入了线程池的概念，为通过认证安全接入的客户端提供线程。同样在该层上可以实现基于SSL的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。
服务层：第二层服务层，主要完成大部分的核心服务功能，包括查询解析、分析、优化、缓存、以及所有的内置函数，所有跨存储引擎的功能也都在这一层实现，包括触发器、存储过程、视图等
引擎层：第三层存储引擎层，存储引擎真正的负责了MySQL中数据的存储和提取，服务器通过API与存储引擎进行通信。不同的存储引擎具有的功能不同，这样我们可以根据自己的实际需要进行选取
存储层：第四层为数据存储层，主要是将数据存储在运行于该设备的文件系统之上，并完成与存储引擎的交互

画出 MySQL 架构图，这种变态问题都能问的出来

MySQL 的查询流程具体是？or 一条SQL语句在MySQL中如何执行的？

客户端请求 —> 连接器（验证用户身份，给予权限） —> 查询缓存（存在缓存则直接返回，不存在则执行后续操作） —> 分析器（对SQL进行词法分析和语法分析操作） —> 优化器（主要对执行的sql优化选择最优的执行方案方法） —> 执行器（执行时会先看用户是否有执行权限，有才去使用这个引擎提供的接口） —> 去引擎层获取数据返回（如果开启查询缓存则会缓存查询结果）

说说MySQL有哪些存储引擎？都有哪些区别？

二、存储引擎

存储引擎是MySQL的组件，用于处理不同表类型的SQL操作。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能，使用不同的存储引擎，还可以获得特定的功能。

使用哪一种引擎可以灵活选择，一个数据库中多个表可以使用不同引擎以满足各种性能和实际需求，使用合适的存储引擎，将会提高整个数据库的性能。

MySQL服务器使用可插拔的存储引擎体系结构，可以从运行中的 MySQL 服务器加载或卸载存储引擎。

查看存储引擎

mysql复制代码-- 查看支持的存储引擎
SHOW ENGINES

-- 查看默认存储引擎
SHOW VARIABLES LIKE 'storage_engine'

--查看具体某一个表所使用的存储引擎，这个默认存储引擎被修改了！
show create table tablename

--准确查看某个数据库中的某一表所使用的存储引擎
show table status like 'tablename'
show table status from database where name="tablename"

设置存储引擎

mysql复制代码-- 建表时指定存储引擎。默认的就是INNODB，不需要设置
CREATE TABLE t1 (i INT) ENGINE = INNODB;
CREATE TABLE t2 (i INT) ENGINE = CSV;
CREATE TABLE t3 (i INT) ENGINE = MEMORY;

-- 修改存储引擎
ALTER TABLE t ENGINE = InnoDB;

-- 修改默认存储引擎，也可以在配置文件my.cnf中修改默认引擎
SET default_storage_engine=NDBCLUSTER;

默认情况下，每当 CREATE TABLE 或 ALTER TABLE 不能使用默认存储引擎时，都会生成一个警告。为了防止在所需的引擎不可用时出现令人困惑的意外行为，可以启用 NO_ENGINE_SUBSTITUTION SQL 模式。如果所需的引擎不可用，则此设置将产生错误而不是警告，并且不会创建或更改表

存储引擎对比

常见的存储引擎就 InnoDB、MyISAM、Memory、NDB。

InnoDB 现在是 MySQL 默认的存储引擎，支持事务、行级锁定和外键

文件存储结构对比

在 MySQL中建立任何一张数据表，在其数据目录对应的数据库目录下都有对应表的 .frm 文件，.frm 文件是用来保存每个数据表的元数据(meta)信息，包括表结构的定义等，与数据库存储引擎无关，也就是任何存储引擎的数据表都必须有.frm文件，命名方式为数据表名.frm，如user.frm。

查看MySQL 数据保存在哪里：show variables like 'data%'

MyISAM 物理文件结构为：

.frm文件：与表相关的元数据信息都存放在frm文件，包括表结构的定义信息等
.MYD (MYData) 文件：MyISAM 存储引擎专用，用于存储MyISAM 表的数据
.MYI (MYIndex)文件：MyISAM 存储引擎专用，用于存储MyISAM 表的索引相关信息

InnoDB 物理文件结构为：

.frm 文件：与表相关的元数据信息都存放在frm文件，包括表结构的定义信息等
.ibd 文件或 .ibdata 文件：这两种文件都是存放 InnoDB 数据的文件，之所以有两种文件形式存放 InnoDB 的数据，是因为 InnoDB 的数据存储方式能够通过配置来决定是使用共享表空间存放存储数据，还是用独享表空间存放存储数据。

独享表空间存储方式使用.ibd文件，并且每个表一个.ibd文件
共享表空间存储方式使用.ibdata文件，所有表共同使用一个.ibdata文件（或多个，可自己配置）

ps：正经公司，这些都有专业运维去做，数据备份、恢复啥的，让我一个 Javaer 搞这的话，加钱不？

面试这么回答

InnoDB 支持事务，MyISAM 不支持事务。这是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一；
InnoDB 支持外键，而 MyISAM 不支持。对一个包含外键的 InnoDB 表转为 MYISAM 会失败；
InnoDB 是聚簇索引，MyISAM 是非聚簇索引。聚簇索引的文件存放在主键索引的叶子节点上，因此 InnoDB 必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。而 MyISAM 是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。
InnoDB 不保存表的具体行数，执行 select count(*) from table 时需要全表扫描。而 MyISAM 用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快；
InnoDB 最小的锁粒度是行锁，MyISAM 最小的锁粒度是表锁。一个更新语句会锁住整张表，导致其他查询和更新都会被阻塞，因此并发访问受限。这也是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一；

对比项	MyISAM	InnoDB
主外键	不支持	支持
事务	不支持	支持
行表锁	表锁，即使操作一条记录也会锁住整个表，不适合高并发的操作	行锁,操作时只锁某一行，不对其它行有影响，适合高并发的操作
缓存	只缓存索引，不缓存真实数据	不仅缓存索引还要缓存真实数据，对内存要求较高，而且内存大小对性能有决定性的影响
表空间	小	大
关注点	性能	事务
默认安装	是	是

一张表，里面有ID自增主键，当insert了17条记录之后，删除了第15,16,17条记录，再把Mysql重启，再insert一条记录，这条记录的ID是18还是15 ？

如果表的类型是MyISAM，那么是18。因为MyISAM表会把自增主键的最大ID 记录到数据文件中，重启MySQL自增主键的最大ID也不会丢失；

如果表的类型是InnoDB，那么是15。因为InnoDB 表只是把自增主键的最大ID记录到内存中，所以重启数据库或对表进行OPTION操作，都会导致最大ID丢失。

哪个存储引擎执行 select count(*) 更快，为什么?

MyISAM更快，因为MyISAM内部维护了一个计数器，可以直接调取。

在 MyISAM 存储引擎中，把表的总行数存储在磁盘上，当执行 select count(*) from t 时，直接返回总数据。
在 InnoDB 存储引擎中，跟 MyISAM 不一样，没有将总行数存储在磁盘上，当执行 select count(*) from t 时，会先把数据读出来，一行一行的累加，最后返回总数量。

InnoDB 中 count(*) 语句是在执行的时候，全表扫描统计总数量，所以当数据越来越大时，语句就越来越耗时了，为什么 InnoDB 引擎不像 MyISAM 引擎一样，将总行数存储到磁盘上？这跟 InnoDB 的事务特性有关，由于多版本并发控制（MVCC）的原因，InnoDB 表“应该返回多少行”也是不确定的。

三、数据类型

主要包括以下五大类：

整数类型：BIT、BOOL、TINY INT、SMALL INT、MEDIUM INT、 INT、 BIG INT
浮点数类型：FLOAT、DOUBLE、DECIMAL
字符串类型：CHAR、VARCHAR、TINY TEXT、TEXT、MEDIUM TEXT、LONGTEXT、TINY BLOB、BLOB、MEDIUM BLOB、LONG BLOB
日期类型：Date、DateTime、TimeStamp、Time、Year
其他数据类型：BINARY、VARBINARY、ENUM、SET、Geometry、Point、MultiPoint、LineString、MultiLineString、Polygon、GeometryCollection等

CHAR 和 VARCHAR 的区别？

char是固定长度，varchar长度可变：

char(n) 和 varchar(n) 中括号中 n 代表字符的个数，并不代表字节个数，比如 CHAR(30) 就可以存储 30 个字符。

存储时，前者不管实际存储数据的长度，直接按 char 规定的长度分配存储空间；而后者会根据实际存储的数据分配最终的存储空间

相同点：

char(n)，varchar(n)中的n都代表字符的个数
超过char，varchar最大长度n的限制后，字符串会被截断。

不同点：

char不论实际存储的字符数都会占用n个字符的空间，而varchar只会占用实际字符应该占用的字节空间加1（实际长度length，0<=length<255）或加2（length>255）。因为varchar保存数据时除了要保存字符串之外还会加一个字节来记录长度（如果列声明长度大于255则使用两个字节来保存长度）。
能存储的最大空间限制不一样：char的存储上限为255字节。
char在存储时会截断尾部的空格，而varchar不会。

char是适合存储很短的、一般固定长度的字符串。例如，char非常适合存储密码的MD5值，因为这是一个定长的值。对于非常短的列，char比varchar在存储空间上也更有效率。

列的字符串类型可以是什么？

字符串类型是：SET、BLOB、ENUM、CHAR、TEXT、VARCHAR

BLOB和TEXT有什么区别？

BLOB是一个二进制对象，可以容纳可变数量的数据。有四种类型的BLOB：TINYBLOB、BLOB、MEDIUMBLO和 LONGBLOB

TEXT是一个不区分大小写的BLOB。四种TEXT类型：TINYTEXT、TEXT、MEDIUMTEXT 和 LONGTEXT。

BLOB 保存二进制数据，TEXT 保存字符数据。

四、索引

说说你对 MySQL 索引的理解？

数据库索引的原理，为什么要用 B+树，为什么不用二叉树？

聚集索引与非聚集索引的区别？

InnoDB引擎中的索引策略，了解过吗？

创建索引的方式有哪些？

聚簇索引/非聚簇索引，mysql索引底层实现，为什么不用B-tree，为什么不用hash，叶子结点存放的是数据还是指向数据的内存地址，使用索引需要注意的几个地方？

MYSQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构，所以说索引的本质是：数据结构
索引的目的在于提高查询效率，可以类比字典、火车站的车次表、图书的目录等。
可以简单的理解为“排好序的快速查找数据结构”，数据本身之外，数据库还维护者一个满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。下图是一种可能的索引方式示例。

左边的数据表，一共有两列七条记录，最左边的是数据记录的物理地址

为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值，和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在一定的复杂度内获取到对应的数据，从而快速检索出符合条件的记录。

索引本身也很大，不可能全部存储在内存中，一般以索引文件的形式存储在磁盘上
平常说的索引，没有特别指明的话，就是B+树（多路搜索树，不一定是二叉树）结构组织的索引。其中聚集索引，次要索引，覆盖索引，复合索引，前缀索引，唯一索引默认都是使用B+树索引，统称索引。此外还有哈希索引等。

基本语法：

创建：

+ 创建索引：`CREATE [UNIQUE] INDEX indexName ON mytable(username(length));`


如果是CHAR，VARCHAR类型，length可以小于字段实际长度；如果是BLOB和TEXT类型，必须指定 length。
+ 修改表结构(添加索引)：`ALTER table tableName ADD [UNIQUE] INDEX indexName(columnName)`

删除：DROP INDEX [indexName] ON mytable;
查看：SHOW INDEX FROM table_name\G –可以通过添加 \G 来格式化输出信息。
使用ALERT命令

+ `ALTER TABLE tbl_name ADD PRIMARY KEY (column_list):` 该语句添加一个主键，这意味着索引值必须是唯一的，且不能为NULL。
+ `ALTER TABLE tbl_name ADD UNIQUE index_name (column_list` 这条语句创建索引的值必须是唯一的（除了NULL外，NULL可能会出现多次）。
+ `ALTER TABLE tbl_name ADD INDEX index_name (column_list)` 添加普通索引，索引值可出现多次。
+ `ALTER TABLE tbl_name ADD FULLTEXT index_name (column_list)`该语句指定了索引为 FULLTEXT ，用于全文索引。

优势

提高数据检索效率，降低数据库IO成本
降低数据排序的成本，降低CPU的消耗

劣势

索引也是一张表，保存了主键和索引字段，并指向实体表的记录，所以也需要占用内存
虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。
因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件每次更新添加了索引列的字段，
都会调整因为更新所带来的键值变化后的索引信息

MySQL索引分类

数据结构角度

B+树索引
Hash索引
Full-Text全文索引
R-Tree索引

从物理存储角度

聚集索引（clustered index）
非聚集索引（non-clustered index），也叫辅助索引（secondary index）

聚集索引和非聚集索引都是B+树结构

从逻辑角度

主键索引：主键索引是一种特殊的唯一索引，不允许有空值
普通索引或者单列索引：每个索引只包含单个列，一个表可以有多个单列索引
多列索引（复合索引、联合索引）：复合索引指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用复合索引时遵循最左前缀集合
唯一索引或者非唯一索引
空间索引：空间索引是对空间数据类型的字段建立的索引，MYSQL中的空间数据类型有4种，分别是GEOMETRY、POINT、LINESTRING、POLYGON。
MYSQL使用SPATIAL关键字进行扩展，使得能够用于创建正规索引类型的语法创建空间索引。创建空间索引的列，必须将其声明为NOT NULL，空间索引只能在存储引擎为MYISAM的表中创建

为什么MySQL 索引中用B+tree，不用B-tree 或者其他树，为什么不用 Hash 索引

聚簇索引/非聚簇索引，MySQL 索引底层实现，叶子结点存放的是数据还是指向数据的内存地址，使用索引需要注意的几个地方？

使用索引查询一定能提高查询的性能吗？为什么?

MySQL索引结构

首先要明白索引（index）是在存储引擎（storage engine）层面实现的，而不是server层面。不是所有的存储引擎都支持所有的索引类型。即使多个存储引擎支持某一索引类型，它们的实现和行为也可能有所差别。

B+Tree索引

MyISAM 和 InnoDB 存储引擎，都使用 B+Tree的数据结构，它相对与 B-Tree结构，所有的数据都存放在叶子节点上，且把叶子节点通过指针连接到一起，形成了一条数据链表，以加快相邻数据的检索效率。

先了解下 B-Tree 和 B+Tree 的区别

B-Tree

B-Tree是为磁盘等外存储设备设计的一种平衡查找树。

系统从磁盘读取数据到内存时是以磁盘块（block）为基本单位的，位于同一个磁盘块中的数据会被一次性读取出来，而不是需要什么取什么。

InnoDB 存储引擎中有页（Page）的概念，页是其磁盘管理的最小单位。InnoDB 存储引擎中默认每个页的大小为16KB，可通过参数 innodb_page_size 将页的大小设置为 4K、8K、16K，在 MySQL 中可通过如下命令查看页的大小：show variables like 'innodb_page_size';

而系统一个磁盘块的存储空间往往没有这么大，因此 InnoDB 每次申请磁盘空间时都会是若干地址连续磁盘块来达到页的大小 16KB。InnoDB 在把磁盘数据读入到磁盘时会以页为基本单位，在查询数据时如果一个页中的每条数据都能有助于定位数据记录的位置，这将会减少磁盘I/O次数，提高查询效率。

B-Tree 结构的数据可以让系统高效的找到数据所在的磁盘块。为了描述 B-Tree，首先定义一条记录为一个二元组[key, data] ，key为记录的键值，对应表中的主键值，data 为一行记录中除主键外的数据。对于不同的记录，key值互不相同。

一棵m阶的B-Tree有如下特性：

每个节点最多有m个孩子
除了根节点和叶子节点外，其它每个节点至少有Ceil(m/2)个孩子。
若根节点不是叶子节点，则至少有2个孩子
所有叶子节点都在同一层，且不包含其它关键字信息
每个非终端节点包含n个关键字信息（P0,P1,…Pn, k1,…kn）
关键字的个数n满足：ceil(m/2)-1 <= n <= m-1
ki(i=1,…n)为关键字，且关键字升序排序
Pi(i=1,…n)为指向子树根节点的指针。P(i-1)指向的子树的所有节点关键字均小于ki，但都大于k(i-1)

B-Tree 中的每个节点根据实际情况可以包含大量的关键字信息和分支，如下图所示为一个 3 阶的 B-Tree：

每个节点占用一个盘块的磁盘空间，一个节点上有两个升序排序的关键字和三个指向子树根节点的指针，指针存储的是子节点所在磁盘块的地址。两个关键词划分成的三个范围域对应三个指针指向的子树的数据的范围域。以根节点为例，关键字为17和35，P1指针指向的子树的数据范围为小于17，P2指针指向的子树的数据范围为17~35，P3指针指向的子树的数据范围为大于35。

模拟查找关键字29的过程：

根据根节点找到磁盘块1，读入内存。【磁盘I/O操作第1次】
比较关键字29在区间（17,35），找到磁盘块1的指针P2。
根据P2指针找到磁盘块3，读入内存。【磁盘I/O操作第2次】
比较关键字29在区间（26,30），找到磁盘块3的指针P2。
根据P2指针找到磁盘块8，读入内存。【磁盘I/O操作第3次】
在磁盘块8中的关键字列表中找到关键字29。

分析上面过程，发现需要3次磁盘I/O操作，和3次内存查找操作。由于内存中的关键字是一个有序表结构，可以利用二分法查找提高效率。而3次磁盘I/O操作是影响整个B-Tree查找效率的决定因素。B-Tree相对于AVLTree缩减了节点个数，使每次磁盘I/O取到内存的数据都发挥了作用，从而提高了查询效率。

B+Tree

B+Tree 是在 B-Tree 基础上的一种优化，使其更适合实现外存储索引结构，InnoDB 存储引擎就是用 B+Tree 实现其索引结构。

从上一节中的B-Tree结构图中可以看到每个节点中不仅包含数据的key值，还有data值。而每一个页的存储空间是有限的，如果data数据较大时将会导致每个节点（即一个页）能存储的key的数量很小，当存储的数据量很大时同样会导致B-Tree的深度较大，增大查询时的磁盘I/O次数，进而影响查询效率。在B+Tree中，所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储key值信息，这样可以大大加大每个节点存储的key值数量，降低B+Tree的高度。

B+Tree相对于B-Tree有几点不同：

非叶子节点只存储键值信息；
所有叶子节点之间都有一个链指针；
数据记录都存放在叶子节点中

将上一节中的B-Tree优化，由于B+Tree的非叶子节点只存储键值信息，假设每个磁盘块能存储4个键值及指针信息，则变成B+Tree后其结构如下图所示：

通常在B+Tree上有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构。因此可以对B+Tree进行两种查找运算：一种是对于主键的范围查找和分页查找，另一种是从根节点开始，进行随机查找。

B+Tree性质

通过上面的分析，我们知道IO次数取决于b+数的高度h，假设当前数据表的数据为N，每个磁盘块的数据项的数量是m，则有h=㏒(m+1)N，当数据量N一定的情况下，m越大，h越小；而m = 磁盘块的大小 / 数据项的大小，磁盘块的大小也就是一个数据页的大小，是固定的，如果数据项占的空间越小，数据项的数量越多，树的高度越低。这就是为什么每个数据项，即索引字段要尽量的小，比如int占4字节，要比bigint8字节少一半。这也是为什么b+树要求把真实的数据放到叶子节点而不是内层节点，一旦放到内层节点，磁盘块的数据项会大幅度下降，导致树增高。当数据项等于1时将会退化成线性表。
当b+树的数据项是复合的数据结构，比如(name,age,sex)的时候，b+数是按照从左到右的顺序来建立搜索树的，比如当(张三,20,F)这样的数据来检索的时候，b+树会优先比较name来确定下一步的所搜方向，如果name相同再依次比较age和sex，最后得到检索的数据；但当(20,F)这样的没有name的数据来的时候，b+树就不知道下一步该查哪个节点，因为建立搜索树的时候name就是第一个比较因子，必须要先根据name来搜索才能知道下一步去哪里查询。比如当(张三,F)这样的数据来检索时，b+树可以用name来指定搜索方向，但下一个字段age的缺失，所以只能把名字等于张三的数据都找到，然后再匹配性别是F的数据了，这个是非常重要的性质，即索引的最左匹配特性。

MyISAM主键索引与辅助索引的结构

MyISAM引擎的索引文件和数据文件是分离的。MyISAM引擎索引结构的叶子节点的数据域，存放的并不是实际的数据记录，而是数据记录的地址。索引文件与数据文件分离，这样的索引称为”非聚簇索引“。MyISAM的主索引与辅助索引区别并不大，只是主键索引不能有重复的关键字。

在MyISAM中，索引（含叶子节点）存放在单独的.myi文件中，叶子节点存放的是数据的物理地址偏移量（通过偏移量访问就是随机访问，速度很快）。

主索引是指主键索引，键值不可能重复；辅助索引则是普通索引，键值可能重复。

通过索引查找数据的流程：先从索引文件中查找到索引节点，从中拿到数据的文件指针，再到数据文件中通过文件指针定位了具体的数据。辅助索引类似。

InnoDB主键索引与辅助索引的结构

InnoDB引擎索引结构的叶子节点的数据域，存放的就是实际的数据记录（对于主索引，此处会存放表中所有的数据记录；对于辅助索引此处会引用主键，检索的时候通过主键到主键索引中找到对应数据行），或者说，InnoDB的数据文件本身就是主键索引文件，这样的索引被称为”“聚簇索引”，一个表只能有一个聚簇索引。

主键索引：

我们知道InnoDB索引是聚集索引，它的索引和数据是存入同一个.idb文件中的，因此它的索引结构是在同一个树节点中同时存放索引和数据，如下图中最底层的叶子节点有三行数据，对应于数据表中的id、stu_id、name数据项。

在Innodb中，索引分叶子节点和非叶子节点，非叶子节点就像新华字典的目录，单独存放在索引段中，叶子节点则是顺序排列的，在数据段中。Innodb的数据文件可以按照表来切分（只需要开启innodb_file_per_table)，切分后存放在xxx.ibd中，默认不切分，存放在xxx.ibdata中。

辅助（非主键）索引：

这次我们以示例中学生表中的name列建立辅助索引，它的索引结构跟主键索引的结构有很大差别，在最底层的叶子结点有两行数据，第一行的字符串是辅助索引，按照ASCII码进行排序，第二行的整数是主键的值。

这就意味着，对name列进行条件搜索，需要两个步骤：

① 在辅助索引上检索name，到达其叶子节点获取对应的主键；

② 使用主键在主索引上再进行对应的检索操作

这也就是所谓的“回表查询”

InnoDB 索引结构需要注意的点

数据文件本身就是索引文件
表数据文件本身就是按 B+Tree 组织的一个索引结构文件
聚集索引中叶节点包含了完整的数据记录
InnoDB 表必须要有主键，并且推荐使用整型自增主键

正如我们上面介绍 InnoDB 存储结构，索引与数据是共同存储的，不管是主键索引还是辅助索引，在查找时都是通过先查找到索引节点才能拿到相对应的数据，如果我们在设计表结构时没有显式指定索引列的话，MySQL 会从表中选择数据不重复的列建立索引，如果没有符合的列，则 MySQL 自动为 InnoDB 表生成一个隐含字段作为主键，并且这个字段长度为6个字节，类型为整型。

那为什么推荐使用整型自增主键而不是选择UUID？

UUID是字符串，比整型消耗更多的存储空间；
在B+树中进行查找时需要跟经过的节点值比较大小，整型数据的比较运算比字符串更快速；
自增的整型索引在磁盘中会连续存储，在读取一页数据时也是连续；UUID是随机产生的，读取的上下两行数据存储是分散的，不适合执行where id > 5 && id < 20的条件查询语句。
在插入或删除数据时，整型自增主键会在叶子结点的末尾建立新的叶子节点，不会破坏左侧子树的结构；UUID主键很容易出现这样的情况，B+树为了维持自身的特性，有可能会进行结构的重构，消耗更多的时间。

为什么非主键索引结构叶子节点存储的是主键值？

保证数据一致性和节省存储空间，可以这么理解：商城系统订单表会存储一个用户ID作为关联外键，而不推荐存储完整的用户信息，因为当我们用户表中的信息（真实名称、手机号、收货地址···）修改后，不需要再次维护订单表的用户数据，同时也节省了存储空间。

Hash索引

主要就是通过Hash算法（常见的Hash算法有直接定址法、平方取中法、折叠法、除数取余法、随机数法），将数据库字段数据转换成定长的Hash值，与这条数据的行指针一并存入Hash表的对应位置；如果发生Hash碰撞（两个不同关键字的Hash值相同），则在对应Hash键下以链表形式存储。

检索算法：在检索查询时，就再次对待查关键字再次执行相同的Hash算法，得到Hash值，到对应Hash表对应位置取出数据即可，如果发生Hash碰撞，则需要在取值时进行筛选。目前使用Hash索引的数据库并不多，主要有Memory等。

MySQL目前有Memory引擎和NDB引擎支持Hash索引。

full-text全文索引

全文索引也是MyISAM的一种特殊索引类型，主要用于全文索引，InnoDB从MYSQL5.6版本提供对全文索引的支持。
它用于替代效率较低的LIKE模糊匹配操作，而且可以通过多字段组合的全文索引一次性全模糊匹配多个字段。
同样使用B-Tree存放索引数据，但使用的是特定的算法，将字段数据分割后再进行索引（一般每4个字节一次分割），索引文件存储的是分割前的索引字符串集合，与分割后的索引信息，对应Btree结构的节点存储的是分割后的词信息以及它在分割前的索引字符串集合中的位置。

R-Tree空间索引

空间索引是MyISAM的一种特殊索引类型，主要用于地理空间数据类型

为什么Mysql索引要用B+树不是B树？

用B+树不用B树考虑的是IO对性能的影响，B树的每个节点都存储数据，而B+树只有叶子节点才存储数据，所以查找相同数据量的情况下，B树的高度更高，IO更频繁。数据库索引是存储在磁盘上的，当数据量大时，就不能把整个索引全部加载到内存了，只能逐一加载每一个磁盘页（对应索引树的节点）。其中在MySQL底层对B+树进行进一步优化：在叶子节点中是双向链表，且在链表的头结点和尾节点也是循环指向的。

面试官：为何不采用Hash方式？

因为Hash索引底层是哈希表，哈希表是一种以key-value存储数据的结构，所以多个数据在存储关系上是完全没有任何顺序关系的，所以，对于区间查询是无法直接通过索引查询的，就需要全表扫描。所以，哈希索引只适用于等值查询的场景。而B+ Tree是一种多路平衡查询树，所以他的节点是天然有序的（左子节点小于父节点、父节点小于右子节点），所以对于范围查询的时候不需要做全表扫描。

哈希索引不支持多列联合索引的最左匹配规则，如果有大量重复键值得情况下，哈希索引的效率会很低，因为存在哈希碰撞问题。

哪些情况需要创建索引

主键自动建立唯一索引
频繁作为查询条件的字段
查询中与其他表关联的字段，外键关系建立索引
单键/组合索引的选择问题，高并发下倾向创建组合索引
查询中排序的字段，排序字段通过索引访问大幅提高排序速度
查询中统计或分组字段

哪些情况不要创建索引

表记录太少
经常增删改的表
数据重复且分布均匀的表字段，只应该为最经常查询和最经常排序的数据列建立索引（如果某个数据类包含太多的重复数据，建立索引没有太大意义）
频繁更新的字段不适合创建索引（会加重IO负担）
where条件里用不到的字段不创建索引

MySQL高效索引

覆盖索引（Covering Index）,或者叫索引覆盖，也就是平时所说的不需要回表操作

就是select的数据列只用从索引中就能够取得，不必读取数据行，MySQL可以利用索引返回select列表中的字段，而不必根据索引再次读取数据文件，换句话说查询列要被所建的索引覆盖。
索引是高效找到行的一个方法，但是一般数据库也能使用索引找到一个列的数据，因此它不必读取整个行。毕竟索引叶子节点存储了它们索引的数据，当能通过读取索引就可以得到想要的数据，那就不需要读取行了。一个索引包含（覆盖）满足查询结果的数据就叫做覆盖索引。
判断标准

使用explain，可以通过输出的extra列来判断，对于一个索引覆盖查询，显示为using index，MySQL查询优化器在执行查询前会决定是否有索引覆盖查询

五、MySQL查询

count(*) 和 count(1)和count(列名)区别 ps：这道题说法有点多

执行效果上：

count(*)包括了所有的列，相当于行数，在统计结果的时候，不会忽略列值为NULL
count(1)包括了所有列，用1代表代码行，在统计结果的时候，不会忽略列值为NULL
count(列名)只包括列名那一列，在统计结果的时候，会忽略列值为空（这里的空不是只空字符串或者0，而是表示null）的计数，即某个字段值为NULL时，不统计。

执行效率上：

列名为主键，count(列名)会比count(1)快
列名不为主键，count(1)会比count(列名)快
如果表多个列并且没有主键，则 count(1) 的执行效率优于 count(*)
如果有主键，则 select count（主键）的执行效率是最优的
如果表只有一个字段，则 select count(*) 最优。

MySQL中 in和 exists 的区别？

exists：exists对外表用loop逐条查询，每次查询都会查看exists的条件语句，当exists里的条件语句能够返回记录行时（无论记录行是的多少，只要能返回），条件就为真，返回当前loop到的这条记录；反之，如果exists里的条件语句不能返回记录行，则当前loop到的这条记录被丢弃，exists的条件就像一个bool条件，当能返回结果集则为true，不能返回结果集则为false
in：in查询相当于多个or条件的叠加

1 2	mysql复制代码SELECT * FROM A WHERE A.id IN (SELECT id FROM B); SELECT * FROM A WHERE EXISTS (SELECT * from B WHERE B.id = A.id);

如果查询的两个表大小相当，那么用in和exists差别不大。

如果两个表中一个较小，一个是大表，则子查询表大的用exists，子查询表小的用in：

UNION和UNION ALL的区别?

UNION和UNION ALL都是将两个结果集合并为一个，两个要联合的SQL语句字段个数必须一样，而且字段类型要“相容”（一致）；

UNION在进行表连接后会筛选掉重复的数据记录（效率较低），而UNION ALL则不会去掉重复的数据记录；
UNION会按照字段的顺序进行排序，而UNION ALL只是简单的将两个结果合并就返回；

SQL执行顺序

手写

mysql复制代码SELECT DISTINCT <select_list>
FROM  <left_table> <join_type>
JOIN  <right_table> ON <join_condition>
WHERE  <where_condition>
GROUP BY  <group_by_list>
HAVING <having_condition>
ORDER BY <order_by_condition>
LIMIT <limit_number>

机读

mysql复制代码FROM  <left_table>
ON <join_condition>
<join_type> JOIN  <right_table> 
WHERE  <where_condition>
GROUP BY  <group_by_list>
HAVING <having_condition>
SELECT
DISTINCT <select_list>
ORDER BY <order_by_condition>
LIMIT <limit_number>

总结

sql-parse

mysql 的内连接、左连接、右连接有什么区别？

什么是内连接、外连接、交叉连接、笛卡尔积呢？

Join图

sql-joins

六、MySQL 事务

事务的隔离级别有哪些？MySQL的默认隔离级别是什么？

什么是幻读，脏读，不可重复读呢？

MySQL事务的四大特性以及实现原理

MVCC熟悉吗，它的底层原理？

MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，你即需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，这样，这些数据库操作语句就构成一个事务！

ACID — 事务基本要素

事务是由一组SQL语句组成的逻辑处理单元，具有4个属性，通常简称为事务的ACID属性。

A (Atomicity) 原子性：整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样
C (Consistency) 一致性：在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏
I (Isolation)隔离性：一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰
D (Durability) 持久性：在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚

并发事务处理带来的问题

更新丢失（Lost Update)：事务A和事务B选择同一行，然后基于最初选定的值更新该行时，由于两个事务都不知道彼此的存在，就会发生丢失更新问题
脏读(Dirty Reads)：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据
不可重复读（Non-Repeatable Reads)：事务 A 多次读取同一数据，事务B在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果不一致。
幻读（Phantom Reads)：幻读与不可重复读类似。它发生在一个事务A读取了几行数据，接着另一个并发事务B插入了一些数据时。在随后的查询中，事务A就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。

幻读和不可重复读的区别：

不可重复读的重点是修改：在同一事务中，同样的条件，第一次读的数据和第二次读的数据不一样。（因为中间有其他事务提交了修改）
幻读的重点在于新增或者删除：在同一事务中，同样的条件,，第一次和第二次读出来的记录数不一样。（因为中间有其他事务提交了插入/删除）

并发事务处理带来的问题的解决办法：

“更新丢失”通常是应该完全避免的。但防止更新丢失，并不能单靠数据库事务控制器来解决，需要应用程序对要更新的数据加必要的锁来解决，因此，防止更新丢失应该是应用的责任。
“脏读” 、 “不可重复读”和“幻读” ，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决：

+ 一种是加锁：在读取数据前，对其加锁，阻止其他事务对数据进行修改。
+ 另一种是数据多版本并发控制（MultiVersion Concurrency Control，简称 **MVCC** 或 MCC），也称为多版本数据库：不用加任何锁， 通过一定机制生成一个数据请求时间点的一致性数据快照 （Snapshot)， 并用这个快照来提供一定级别 （语句级或事务级） 的一致性读取。从用户的角度来看，好象是数据库可以提供同一数据的多个版本。

事务隔离级别

数据库事务的隔离级别有4种，由低到高分别为

READ-UNCOMMITTED(读未提交)： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
READ-COMMITTED(读已提交)： 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
REPEATABLE-READ(可重复读)： 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

查看当前数据库的事务隔离级别：

1	mysql复制代码show variables like 'tx_isolation'

下面通过事例一一阐述在事务的并发操作中可能会出现脏读，不可重复读，幻读和事务隔离级别的联系。

数据库的事务隔离越严格，并发副作用越小，但付出的代价就越大，因为事务隔离实质上就是使事务在一定程度上“串行化”进行，这显然与“并发”是矛盾的。同时，不同的应用对读一致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读”和“幻读”并不敏感，可能更关心数据并发访问的能力。

Read uncommitted

读未提交，就是一个事务可以读取另一个未提交事务的数据。

事例：老板要给程序员发工资，程序员的工资是3.6万/月。但是发工资时老板不小心按错了数字，按成3.9万/月，该钱已经打到程序员的户口，但是事务还没有提交，就在这时，程序员去查看自己这个月的工资，发现比往常多了3千元，以为涨工资了非常高兴。但是老板及时发现了不对，马上回滚差点就提交了的事务，将数字改成3.6万再提交。

分析：实际程序员这个月的工资还是3.6万，但是程序员看到的是3.9万。他看到的是老板还没提交事务时的数据。这就是脏读。

那怎么解决脏读呢？Read committed！读提交，能解决脏读问题。

Read committed

读提交，顾名思义，就是一个事务要等另一个事务提交后才能读取数据。

事例：程序员拿着信用卡去享受生活（卡里当然是只有3.6万），当他埋单时（程序员事务开启），收费系统事先检测到他的卡里有3.6万，就在这个时候！！程序员的妻子要把钱全部转出充当家用，并提交。当收费系统准备扣款时，再检测卡里的金额，发现已经没钱了（第二次检测金额当然要等待妻子转出金额事务提交完）。程序员就会很郁闷，明明卡里是有钱的…

分析：这就是读提交，若有事务对数据进行更新（UPDATE）操作时，读操作事务要等待这个更新操作事务提交后才能读取数据，可以解决脏读问题。但在这个事例中，出现了一个事务范围内两个相同的查询却返回了不同数据，这就是不可重复读。

那怎么解决可能的不可重复读问题？Repeatable read ！

Repeatable read

重复读，就是在开始读取数据（事务开启）时，不再允许修改操作。 MySQL的默认事务隔离级别

事例：程序员拿着信用卡去享受生活（卡里当然是只有3.6万），当他埋单时（事务开启，不允许其他事务的UPDATE修改操作），收费系统事先检测到他的卡里有3.6万。这个时候他的妻子不能转出金额了。接下来收费系统就可以扣款了。

分析：重复读可以解决不可重复读问题。写到这里，应该明白的一点就是，不可重复读对应的是修改，即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入INSERT操作，而不是UPDATE操作。

什么时候会出现幻读？

事例：程序员某一天去消费，花了2千元，然后他的妻子去查看他今天的消费记录（全表扫描FTS，妻子事务开启），看到确实是花了2千元，就在这个时候，程序员花了1万买了一部电脑，即新增INSERT了一条消费记录，并提交。当妻子打印程序员的消费记录清单时（妻子事务提交），发现花了1.2万元，似乎出现了幻觉，这就是幻读。

那怎么解决幻读问题？Serializable！

Serializable 序列化

Serializable 是最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。简单来说，Serializable会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用问题。这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。

比较

事务隔离级别	读数据一致性	脏读	不可重复读	幻读
读未提交（read-uncommitted）	最低级被，只能保证不读取物理上损坏的数据	是	是	是
读已提交（read-committed）	语句级	否	是	是
可重复读（repeatable-read）	事务级	否	否	是
串行化（serializable）	最高级别，事务级	否	否	否

需要说明的是，事务隔离级别和数据访问的并发性是对立的，事务隔离级别越高并发性就越差。所以要根据具体的应用来确定合适的事务隔离级别，这个地方没有万能的原则。

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）。我们可以通过SELECT @@tx_isolation;命令来查看，MySQL 8.0 该命令改为SELECT @@transaction_isolation;

这里需要注意的是：与 SQL 标准不同的地方在于InnoDB 存储引擎在 **REPEATABLE-READ（可重读）**事务隔离级别下使用的是Next-Key Lock 算法，因此可以避免幻读的产生，这与其他数据库系统(如 SQL Server)是不同的。所以说InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）已经可以完全保证事务的隔离性要求，即达到了 SQL标准的 **SERIALIZABLE(可串行化)**隔离级别，而且保留了比较好的并发性能。

因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是READ-COMMITTED(读已提交):，但是你要知道的是InnoDB 存储引擎默认使用 **REPEATABLE-READ（可重读）**并不会有任何性能损失。

MVCC 多版本并发控制

MySQL的大多数事务型存储引擎实现都不是简单的行级锁。基于提升并发性考虑，一般都同时实现了多版本并发控制（MVCC），包括Oracle、PostgreSQL。只是实现机制各不相同。

可以认为 MVCC 是行级锁的一个变种，但它在很多情况下避免了加锁操作，因此开销更低。虽然实现机制有所不同，但大都实现了非阻塞的读操作，写操作也只是锁定必要的行。

MVCC 的实现是通过保存数据在某个时间点的快照来实现的。也就是说不管需要执行多长时间，每个事物看到的数据都是一致的。

典型的MVCC实现方式，分为乐观（optimistic）并发控制和悲观（pressimistic）并发控制。下边通过 InnoDB的简化版行为来说明 MVCC 是如何工作的。

InnoDB 的 MVCC，是通过在每行记录后面保存两个隐藏的列来实现。这两个列，一个保存了行的创建时间，一个保存行的过期时间（删除时间）。当然存储的并不是真实的时间，而是系统版本号（system version number）。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。

REPEATABLE READ（可重读）隔离级别下MVCC如何工作：

SELECT

InnoDB会根据以下两个条件检查每行记录：

+ InnoDB只查找版本早于当前事务版本的数据行，这样可以确保事务读取的行，要么是在开始事务之前已经存在要么是事务自身插入或者修改过的
+ 行的删除版本号要么未定义，要么大于当前事务版本号，这样可以确保事务读取到的行在事务开始之前未被删除只有符合上述两个条件的才会被查询出来

INSERT：InnoDB为新插入的每一行保存当前系统版本号作为行版本号
DELETE：InnoDB为删除的每一行保存当前系统版本号作为行删除标识
UPDATE：InnoDB为插入的一行新纪录保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为删除标识

保存这两个额外系统版本号，使大多数操作都不用加锁。使数据操作简单，性能很好，并且也能保证只会读取到符合要求的行。不足之处是每行记录都需要额外的存储空间，需要做更多的行检查工作和一些额外的维护工作。

MVCC 只在 COMMITTED READ（读提交）和REPEATABLE READ（可重复读）两种隔离级别下工作。

事务日志

InnoDB 使用日志来减少提交事务时的开销。因为日志中已经记录了事务，就无须在每个事务提交时把缓冲池的脏块刷新(flush)到磁盘中。

事务修改的数据和索引通常会映射到表空间的随机位置，所以刷新这些变更到磁盘需要很多随机 IO。

InnoDB 假设使用常规磁盘，随机IO比顺序IO昂贵得多，因为一个IO请求需要时间把磁头移到正确的位置，然后等待磁盘上读出需要的部分，再转到开始位置。

InnoDB 用日志把随机IO变成顺序IO。一旦日志安全写到磁盘，事务就持久化了，即使断电了，InnoDB可以重放日志并且恢复已经提交的事务。

InnoDB 使用一个后台线程智能地刷新这些变更到数据文件。这个线程可以批量组合写入，使得数据写入更顺序，以提高效率。

事务日志可以帮助提高事务效率：

使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。
事务日志采用的是追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快得多。
事务日志持久以后，内存中被修改的数据在后台可以慢慢刷回到磁盘。
如果数据的修改已经记录到事务日志并持久化，但数据本身没有写回到磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这一部分修改的数据。

目前来说，大多数存储引擎都是这样实现的，我们通常称之为预写式日志（Write-Ahead Logging），修改数据需要写两次磁盘。

事务的实现

事务的实现是基于数据库的存储引擎。不同的存储引擎对事务的支持程度不一样。MySQL 中支持事务的存储引擎有 InnoDB 和 NDB。

事务的实现就是如何实现ACID特性。

事务的隔离性是通过锁实现，而事务的原子性、一致性和持久性则是通过事务日志实现。

事务是如何通过日志来实现的，说得越深入越好。

事务日志包括：重做日志redo和回滚日志undo

redo log（重做日志）实现持久化和原子性

在innoDB的存储引擎中，事务日志通过重做(redo)日志和innoDB存储引擎的日志缓冲(InnoDB Log Buffer)实现。事务开启时，事务中的操作，都会先写入存储引擎的日志缓冲中，在事务提交之前，这些缓冲的日志都需要提前刷新到磁盘上持久化，这就是DBA们口中常说的“日志先行”(Write-Ahead Logging)。当事务提交之后，在Buffer Pool中映射的数据文件才会慢慢刷新到磁盘。此时如果数据库崩溃或者宕机，那么当系统重启进行恢复时，就可以根据redo log中记录的日志，把数据库恢复到崩溃前的一个状态。未完成的事务，可以继续提交，也可以选择回滚，这基于恢复的策略而定。

在系统启动的时候，就已经为redo log分配了一块连续的存储空间，以顺序追加的方式记录Redo Log，通过顺序IO来改善性能。所有的事务共享redo log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起。

undo log（回滚日志） 实现一致性

undo log 主要为事务的回滚服务。在事务执行的过程中，除了记录redo log，还会记录一定量的undo log。undo log记录了数据在每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作。单个事务的回滚，只会回滚当前事务做的操作，并不会影响到其他的事务做的操作。

Undo记录的是已部分完成并且写入硬盘的未完成的事务，默认情况下回滚日志是记录下表空间中的（共享表空间或者独享表空间）

二种日志均可以视为一种恢复操作，redo_log是恢复提交事务修改的页操作，而undo_log是回滚行记录到特定版本。二者记录的内容也不同，redo_log是物理日志，记录页的物理修改操作，而undo_log是逻辑日志，根据每行记录进行记录。

又引出个问题：你知道MySQL 有多少种日志吗？

错误日志：记录出错信息，也记录一些警告信息或者正确的信息。
查询日志：记录所有对数据库请求的信息，不论这些请求是否得到了正确的执行。
慢查询日志：设置一个阈值，将运行时间超过该值的所有SQL语句都记录到慢查询的日志文件中。
二进制日志：记录对数据库执行更改的所有操作。
中继日志：中继日志也是二进制日志，用来给slave 库恢复
事务日志：重做日志redo和回滚日志undo

分布式事务相关问题，可能还会问到 2PC、3PC，，，

MySQL对分布式事务的支持

分布式事务的实现方式有很多，既可以采用 InnoDB 提供的原生的事务支持，也可以采用消息队列来实现分布式事务的最终一致性。这里我们主要聊一下 InnoDB 对分布式事务的支持。

MySQL 从 5.0.3 InnoDB 存储引擎开始支持XA协议的分布式事务。一个分布式事务会涉及多个行动，这些行动本身是事务性的。所有行动都必须一起成功完成，或者一起被回滚。

在MySQL中，使用分布式事务涉及一个或多个资源管理器和一个事务管理器。

如图，MySQL 的分布式事务模型。模型中分三块：应用程序（AP）、资源管理器（RM）、事务管理器（TM）:

应用程序：定义了事务的边界，指定需要做哪些事务；
资源管理器：提供了访问事务的方法，通常一个数据库就是一个资源管理器；
事务管理器：协调参与了全局事务中的各个事务。

分布式事务采用两段式提交（two-phase commit）的方式：

第一阶段所有的事务节点开始准备，告诉事务管理器ready。
第二阶段事务管理器告诉每个节点是commit还是rollback。如果有一个节点失败，就需要全局的节点全部rollback，以此保障事务的原子性。

七、MySQL锁机制

数据库的乐观锁和悲观锁？

MySQL 中有哪几种锁，列举一下？

MySQL中InnoDB引擎的行锁是怎么实现的？

MySQL 间隙锁有没有了解，死锁有没有了解，写一段会造成死锁的 sql 语句，死锁发生了如何解决，MySQL 有没有提供什么机制去解决死锁

锁是计算机协调多个进程或线程并发访问某一资源的机制。

在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。数据库锁定机制简单来说，就是数据库为了保证数据的一致性，而使各种共享资源在被并发访问变得有序所设计的一种规则。

打个比方，我们到淘宝上买一件商品，商品只有一件库存，这个时候如果还有另一个人买，那么如何解决是你买到还是另一个人买到的问题？这里肯定要用到事物，我们先从库存表中取出物品数量，然后插入订单，付款后插入付款表信息，然后更新商品数量。在这个过程中，使用锁可以对有限的资源进行保护，解决隔离和并发的矛盾。

锁的分类

从对数据操作的类型分类：

读锁（共享锁）：针对同一份数据，多个读操作可以同时进行，不会互相影响
写锁（排他锁）：当前写操作没有完成前，它会阻断其他写锁和读锁

从对数据操作的粒度分类：

为了尽可能提高数据库的并发度，每次锁定的数据范围越小越好，理论上每次只锁定当前操作的数据的方案会得到最大的并发度，但是管理锁是很耗资源的事情（涉及获取，检查，释放锁等动作），因此数据库系统需要在高并发响应和系统性能两方面进行平衡，这样就产生了“锁粒度（Lock granularity）”的概念。

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低（MyISAM 和 MEMORY 存储引擎采用的是表级锁）；
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高（InnoDB 存储引擎既支持行级锁也支持表级锁，但默认情况下是采用行级锁）；
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

适用：从锁的角度来说，表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（OLTP）系统。

	行锁	表锁	页锁
MyISAM		√
BDB		√	√
InnoDB	√	√
Memory		√

MyISAM 表锁

MyISAM 的表锁有两种模式：

表共享读锁（Table Read Lock）：不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求；
表独占写锁（Table Write Lock）：会阻塞其他用户对同一表的读和写操作；

MyISAM 表的读操作与写操作之间，以及写操作之间是串行的。当一个线程获得对一个表的写锁后，只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待，直到锁被释放为止。

默认情况下，写锁比读锁具有更高的优先级：当一个锁释放时，这个锁会优先给写锁队列中等候的获取锁请求，然后再给读锁队列中等候的获取锁请求。

InnoDB 行锁

InnoDB 实现了以下两种类型的行锁：

共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
排他锁（X）：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。

为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB 还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁：

意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的 IS 锁。
意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的 IX 锁。

索引失效会导致行锁变表锁。比如 vchar 查询不写单引号的情况。

加锁机制

乐观锁与悲观锁是两种并发控制的思想，可用于解决丢失更新问题

乐观锁会“乐观地”假定大概率不会发生并发更新冲突，访问、处理数据过程中不加锁，只在更新数据时再根据版本号或时间戳判断是否有冲突，有则处理，无则提交事务。用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式

悲观锁会“悲观地”假定大概率会发生并发更新冲突，访问、处理数据前就加排他锁，在整个数据处理过程中锁定数据，事务提交或回滚后才释放锁。另外与乐观锁相对应的，悲观锁是由数据库自己实现了的，要用的时候，我们直接调用数据库的相关语句就可以了。

锁模式(InnoDB有三种行锁的算法)

记录锁(Record Locks)：单个行记录上的锁。对索引项加锁，锁定符合条件的行。其他事务不能修改和删除加锁项；

1	mysql复制代码SELECT * FROM table WHERE id = 1 FOR UPDATE;

它会在 id=1 的记录上加上记录锁，以阻止其他事务插入，更新，删除 id=1 这一行

在通过主键索引与唯一索引对数据行进行 UPDATE 操作时，也会对该行数据加记录锁：

1 2	mysql复制代码-- id 列为主键列或唯一索引列 UPDATE SET age = 50 WHERE id = 1;

间隙锁（Gap Locks）：当我们使用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁。对于键值在条件范围内但并不存在的记录，叫做“间隙”。

InnoDB 也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁。

对索引项之间的“间隙”加锁，锁定记录的范围（对第一条记录前的间隙或最后一条将记录后的间隙加锁），不包含索引项本身。其他事务不能在锁范围内插入数据，这样就防止了别的事务新增幻影行。

间隙锁基于非唯一索引，它锁定一段范围内的索引记录。间隙锁基于下面将会提到的Next-Key Locking 算法，请务必牢记：使用间隙锁锁住的是一个区间，而不仅仅是这个区间中的每一条数据。

1	mysql复制代码SELECT * FROM table WHERE id BETWEN 1 AND 10 FOR UPDATE;

即所有在（1，10）区间内的记录行都会被锁住，所有id 为 2、3、4、5、6、7、8、9 的数据行的插入会被阻塞，但是 1 和 10 两条记录行并不会被锁住。

GAP锁的目的，是为了防止同一事务的两次当前读，出现幻读的情况

临键锁(Next-key Locks)： 临键锁，是记录锁与间隙锁的组合，它的封锁范围，既包含索引记录，又包含索引区间。(临键锁的主要目的，也是为了避免幻读(Phantom Read)。如果把事务的隔离级别降级为RC，临键锁则也会失效。)

Next-Key 可以理解为一种特殊的间隙锁，也可以理解为一种特殊的算法。通过临建锁可以解决幻读的问题。每个数据行上的非唯一索引列上都会存在一把临键锁，当某个事务持有该数据行的临键锁时，会锁住一段左开右闭区间的数据。需要强调的一点是，InnoDB 中行级锁是基于索引实现的，临键锁只与非唯一索引列有关，在唯一索引列（包括主键列）上不存在临键锁。

对于行的查询，都是采用该方法，主要目的是解决幻读的问题。

select for update有什么含义，会锁表还是锁行还是其他

for update 仅适用于InnoDB，且必须在事务块(BEGIN/COMMIT)中才能生效。在进行事务操作时，通过“for update”语句，MySQL会对查询结果集中每行数据都添加排他锁，其他线程对该记录的更新与删除操作都会阻塞。排他锁包含行锁、表锁。

InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！
假设有个表单 products ，里面有id跟name二个栏位，id是主键。

明确指定主键，并且有此笔资料，row lock

1 2	mysql复制代码SELECT * FROM products WHERE id='3' FOR UPDATE; SELECT * FROM products WHERE id='3' and type=1 FOR UPDATE;

明确指定主键，若查无此笔资料，无lock

1	mysql复制代码SELECT * FROM products WHERE id='-1' FOR UPDATE;

无主键，table lock

1	mysql复制代码SELECT * FROM products WHERE name='Mouse' FOR UPDATE;

主键不明确，table lock

1	mysql复制代码SELECT * FROM products WHERE id<>'3' FOR UPDATE;

主键不明确，table lock

1	mysql复制代码SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;

注1: FOR UPDATE仅适用于InnoDB，且必须在交易区块(BEGIN/COMMIT)中才能生效。
注2: 要测试锁定的状况，可以利用MySQL的Command Mode ，开二个视窗来做测试。

MySQL 遇到过死锁问题吗，你是如何解决的？

死锁

死锁产生：

死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环
当事务试图以不同的顺序锁定资源时，就可能产生死锁。多个事务同时锁定同一个资源时也可能会产生死锁
锁的行为和顺序和存储引擎相关。以同样的顺序执行语句，有些存储引擎会产生死锁有些不会——死锁有双重原因：真正的数据冲突；存储引擎的实现方式。

检测死锁：数据库系统实现了各种死锁检测和死锁超时的机制。InnoDB存储引擎能检测到死锁的循环依赖并立即返回一个错误。

死锁恢复：死锁发生以后，只有部分或完全回滚其中一个事务，才能打破死锁，InnoDB目前处理死锁的方法是，将持有最少行级排他锁的事务进行回滚。所以事务型应用程序在设计时必须考虑如何处理死锁，多数情况下只需要重新执行因死锁回滚的事务即可。

外部锁的死锁检测：发生死锁后，InnoDB 一般都能自动检测到，并使一个事务释放锁并回退，另一个事务获得锁，继续完成事务。但在涉及外部锁，或涉及表锁的情况下，InnoDB 并不能完全自动检测到死锁，这需要通过设置锁等待超时参数 innodb_lock_wait_timeout 来解决

死锁影响性能：死锁会影响性能而不是会产生严重错误，因为InnoDB会自动检测死锁状况并回滚其中一个受影响的事务。在高并发系统上，当许多线程等待同一个锁时，死锁检测可能导致速度变慢。有时当发生死锁时，禁用死锁检测（使用innodb_deadlock_detect配置选项）可能会更有效，这时可以依赖innodb_lock_wait_timeout设置进行事务回滚。

MyISAM避免死锁：

在自动加锁的情况下，MyISAM 总是一次获得 SQL 语句所需要的全部锁，所以 MyISAM 表不会出现死锁。

InnoDB避免死锁：

为了在单个InnoDB表上执行多个并发写入操作时避免死锁，可以在事务开始时通过为预期要修改的每个元祖（行）使用SELECT ... FOR UPDATE语句来获取必要的锁，即使这些行的更改语句是在之后才执行的。
在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应先申请共享锁、更新时再申请排他锁，因为这时候当用户再申请排他锁时，其他事务可能又已经获得了相同记录的共享锁，从而造成锁冲突，甚至死锁
如果事务需要修改或锁定多个表，则应在每个事务中以相同的顺序使用加锁语句。在应用中，如果不同的程序会并发存取多个表，应尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会
通过SELECT ... LOCK IN SHARE MODE获取行的读锁后，如果当前事务再需要对该记录进行更新操作，则很有可能造成死锁。
改变事务隔离级别

如果出现死锁，可以用 show engine innodb status; 命令来确定最后一个死锁产生的原因。返回结果中包括死锁相关事务的详细信息，如引发死锁的 SQL 语句，事务已经获得的锁，正在等待什么锁，以及被回滚的事务等。据此可以分析死锁产生的原因和改进措施。

八、MySQL调优

日常工作中你是怎么优化SQL的？

SQL优化的一般步骤是什么，怎么看执行计划（explain），如何理解其中各个字段的含义？

如何写sql能够有效的使用到复合索引？

一条sql执行过长的时间，你如何优化，从哪些方面入手？

什么是最左前缀原则？什么是最左匹配原则？

影响mysql的性能因素

业务需求对MySQL的影响(合适合度)
存储定位对MySQL的影响

+ 不适合放进MySQL的数据
    - 二进制多媒体数据
    - 流水队列数据
    - 超大文本数据
+ 需要放进缓存的数据
    - 系统各种配置及规则数据
    - 活跃用户的基本信息数据
    - 活跃用户的个性化定制信息数据
    - 准实时的统计信息数据
    - 其他一些访问频繁但变更较少的数据

Schema设计对系统的性能影响

+ 尽量减少对数据库访问的请求
+ 尽量减少无用数据的查询请求

硬件环境对系统性能的影响

性能分析

MySQL Query Optimizer

MySQL 中有专门负责优化 SELECT 语句的优化器模块，主要功能：通过计算分析系统中收集到的统计信息，为客户端请求的 Query 提供他认为最优的执行计划（他认为最优的数据检索方式，但不见得是 DBA 认为是最优的，这部分最耗费时间）
当客户端向 MySQL 请求一条 Query，命令解析器模块完成请求分类，区别出是 SELECT 并转发给 MySQL Query Optimize r时，MySQL Query Optimizer 首先会对整条 Query 进行优化，处理掉一些常量表达式的预算，直接换算成常量值。并对 Query 中的查询条件进行简化和转换，如去掉一些无用或显而易见的条件、结构调整等。然后分析 Query 中的 Hint 信息（如果有），看显示 Hint 信息是否可以完全确定该 Query 的执行计划。如果没有 Hint 或 Hint 信息还不足以完全确定执行计划，则会读取所涉及对象的统计信息，根据 Query 进行写相应的计算分析，然后再得出最后的执行计划。

MySQL常见瓶颈

CPU：CPU在饱和的时候一般发生在数据装入内存或从磁盘上读取数据时候
IO：磁盘I/O瓶颈发生在装入数据远大于内存容量的时候
服务器硬件的性能瓶颈：top，free，iostat 和 vmstat来查看系统的性能状态

性能下降SQL慢执行时间长等待时间长原因分析

查询语句写的烂
索引失效（单值、复合）
关联查询太多join（设计缺陷或不得已的需求）
服务器调优及各个参数设置（缓冲、线程数等）

MySQL常见性能分析手段

在优化MySQL时，通常需要对数据库进行分析，常见的分析手段有慢查询日志，EXPLAIN 分析查询，profiling分析以及show命令查询系统状态及系统变量，通过定位分析性能的瓶颈，才能更好的优化数据库系统的性能。

性能瓶颈定位

我们可以通过 show 命令查看 MySQL 状态及变量，找到系统的瓶颈：

mysql复制代码Mysql> show status ——显示状态信息（扩展show status like ‘XXX’）

Mysql> show variables ——显示系统变量（扩展show variables like ‘XXX’）

Mysql> show innodb status ——显示InnoDB存储引擎的状态

Mysql> show processlist ——查看当前SQL执行，包括执行状态、是否锁表等

Shell> mysqladmin variables -u username -p password——显示系统变量

Shell> mysqladmin extended-status -u username -p password——显示状态信息

Explain(执行计划)

是什么：使用 Explain 关键字可以模拟优化器执行SQL查询语句，从而知道 MySQL 是如何处理你的 SQL 语句的。分析你的查询语句或是表结构的性能瓶颈

能干吗：

表的读取顺序
数据读取操作的操作类型
哪些索引可以使用
哪些索引被实际使用
表之间的引用
每张表有多少行被优化器查询

怎么玩：

Explain + SQL语句
执行计划包含的信息（如果有分区表的话还会有partitions）

expalin

各字段解释

id（select 查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序）

+ id相同，执行顺序从上往下
+ id全不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行
+ id部分相同，执行顺序是先按照数字大的先执行，然后数字相同的按照从上往下的顺序执行

select_type（查询类型，用于区别普通查询、联合查询、子查询等复杂查询）

+ **SIMPLE** ：简单的select查询，查询中不包含子查询或UNION
+ **PRIMARY**：查询中若包含任何复杂的子部分，最外层查询被标记为PRIMARY
+ **SUBQUERY**：在select或where列表中包含了子查询
+ **DERIVED**：在from列表中包含的子查询被标记为DERIVED，MySQL会递归执行这些子查询，把结果放在临时表里
+ **UNION**：若第二个select出现在UNION之后，则被标记为UNION，若UNION包含在from子句的子查询中，外层select将被标记为DERIVED
+ **UNION RESULT**：从UNION表获取结果的select

table（显示这一行的数据是关于哪张表的）
type（显示查询使用了那种类型，从最好到最差依次排列 system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL ）

+ system：表只有一行记录（等于系统表），是 const 类型的特例，平时不会出现
+ const：表示通过索引一次就找到了，const 用于比较 primary key 或 unique 索引，因为只要匹配一行数据，所以很快，如将主键置于 where 列表中，mysql 就能将该查询转换为一个常量
+ eq\_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配，常见于主键或唯一索引扫描
+ ref：非唯一性索引扫描，范围匹配某个单独值得所有行。本质上也是一种索引访问，他返回所有匹配某个单独值的行，然而，它可能也会找到多个符合条件的行，多以他应该属于查找和扫描的混合体
+ range：只检索给定范围的行，使用一个索引来选择行。key列显示使用了哪个索引，一般就是在你的where语句中出现了between、<、>、in等的查询，这种范围扫描索引比全表扫描要好，因为它只需开始于索引的某一点，而结束于另一点，不用扫描全部索引
+ index：Full Index Scan，index于ALL区别为index类型只遍历索引树。通常比ALL快，因为索引文件通常比数据文件小。（**也就是说虽然all和index都是读全表，但index是从索引中读取的，而all是从硬盘中读的**）
+ ALL：Full Table Scan，将遍历全表找到匹配的行tip: 一般来说，得保证查询至少达到range级别，最好到达ref

possible_keys（显示可能应用在这张表中的索引，一个或多个，查询涉及到的字段若存在索引，则该索引将被列出，但不一定被查询实际使用）
key

+ 实际使用的索引，如果为NULL，则没有使用索引
+ **查询中若使用了覆盖索引，则该索引和查询的 select 字段重叠，仅出现在key列表中**

explain-key

key_len

+ 表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。在不损失精确性的情况下，长度越短越好
+ key\_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key\_len是根据表定义计算而得，不是通过表内检索出的

ref （显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值）
rows （根据表统计信息及索引选用情况，大致估算找到所需的记录所需要读取的行数）
Extra（包含不适合在其他列中显示但十分重要的额外信息）

1. using filesort: 说明mysql会对数据使用一个外部的索引排序，不是按照表内的索引顺序进行读取。mysql中无法利用索引完成的排序操作称为“文件排序”。常见于order by和group by语句中
2. Using temporary：使用了临时表保存中间结果，mysql在对查询结果排序时使用临时表。常见于排序order by和分组查询group by。
3. using index：表示相应的select操作中使用了覆盖索引，避免访问了表的数据行，效率不错，如果同时出现using where，表明索引被用来执行索引键值的查找；否则索引被用来读取数据而非执行查找操作
4. using where：使用了where过滤
5. using join buffer：使用了连接缓存
6. impossible where：where子句的值总是false，不能用来获取任何元祖
7. select tables optimized away：在没有group by子句的情况下，基于索引优化操作或对于MyISAM存储引擎优化COUNT(\*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化
8. distinct：优化distinct操作，在找到第一匹配的元祖后即停止找同样值的动作

case:

explain-demo

第一行（执行顺序4）：id列为1，表示是union里的第一个select，select_type列的primary表示该查询为外层查询，table列被标记为，表示查询结果来自一个衍生表，其中derived3中3代表该查询衍生自第三个select查询，即id为3的select。【select d1.name……】
第二行（执行顺序2）：id为3，是整个查询中第三个select的一部分。因查询包含在from中，所以为derived。【select id,name from t1 where other_column=’’】
第三行（执行顺序3）：select列表中的子查询select_type为subquery，为整个查询中的第二个select。【select id from t3】
第四行（执行顺序1）：select_type为union，说明第四个select是union里的第二个select，最先执行【select name,id from t2】
第五行（执行顺序5）：代表从union的临时表中读取行的阶段，table列的<union1,4>表示用第一个和第四个select的结果进行union操作。【两个结果union操作】

慢查询日志

MySQL 的慢查询日志是 MySQL 提供的一种日志记录，它用来记录在 MySQL 中响应时间超过阈值的语句，具体指运行时间超过 long_query_time 值的 SQL，则会被记录到慢查询日志中。

long_query_time 的默认值为10，意思是运行10秒以上的语句
默认情况下，MySQL数据库没有开启慢查询日志，需要手动设置参数开启

查看开启状态

1	mysql复制代码SHOW VARIABLES LIKE '%slow_query_log%'

开启慢查询日志

临时配置：

1
2
3

mysql复制代码mysql> set global slow_query_log='ON';
mysql> set global slow_query_log_file='/var/lib/mysql/hostname-slow.log';
mysql> set global long_query_time=2;

也可set文件位置，系统会默认给一个缺省文件host_name-slow.log

使用set操作开启慢查询日志只对当前数据库生效，如果MySQL重启则会失效。

永久配置

修改配置文件my.cnf或my.ini，在[mysqld]一行下面加入两个配置参数

mysql复制代码[mysqld]
slow_query_log = ON
slow_query_log_file = /var/lib/mysql/hostname-slow.log
long_query_time = 3

注：log-slow-queries 参数为慢查询日志存放的位置，一般这个目录要有 MySQL 的运行帐号的可写权限，一般都将这个目录设置为 MySQL 的数据存放目录；long_query_time=2 中的 2 表示查询超过两秒才记录；在my.cnf或者 my.ini 中添加 log-queries-not-using-indexes 参数，表示记录下没有使用索引的查询。

可以用 select sleep(4) 验证是否成功开启。

在生产环境中，如果手工分析日志，查找、分析SQL，还是比较费劲的，所以MySQL提供了日志分析工具mysqldumpslow。

通过 mysqldumpslow –help 查看操作帮助信息

得到返回记录集最多的10个SQL

mysqldumpslow -s r -t 10 /var/lib/mysql/hostname-slow.log

得到访问次数最多的10个SQL

mysqldumpslow -s c -t 10 /var/lib/mysql/hostname-slow.log

得到按照时间排序的前10条里面含有左连接的查询语句

mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/hostname-slow.log

也可以和管道配合使用

mysqldumpslow -s r -t 10 /var/lib/mysql/hostname-slow.log | more

也可使用 pt-query-digest 分析 RDS MySQL 慢查询日志

Show Profile 分析查询

通过慢日志查询可以知道哪些 SQL 语句执行效率低下，通过 explain 我们可以得知 SQL 语句的具体执行情况，索引使用等，还可以结合Show Profile命令查看执行状态。

Show Profile 是 MySQL 提供可以用来分析当前会话中语句执行的资源消耗情况。可以用于SQL的调优的测量
默认情况下，参数处于关闭状态，并保存最近15次的运行结果
分析步骤

1. 是否支持，看看当前的mysql版本是否支持



1
mysql复制代码mysql>Show  variables like 'profiling';  --默认是关闭，使用前需要开启


2. 开启功能，默认是关闭，使用前需要开启



1
mysql复制代码mysql>set profiling=1;


3. 运行SQL
4. 查看结果



1
2
3
4
5
6
7
8
9
	mysql复制代码
	```mysql> show profiles;
+----------+------------+---------------------------------+
| Query\_ID | Duration | Query |
+----------+------------+---------------------------------+
| 1 | 0.00385450 | show variables like "profiling" |
| 2 | 0.00170050 | show variables like "profiling" |
| 3 | 0.00038025 | select \* from t\_base\_user |
+----------+------------+---------------------------------+

复制代码


5. 诊断SQL，show profile cpu,block io for query id(上一步前面的问题SQL数字号码)
6. 日常开发需要注意的结论


	+ converting HEAP to MyISAM 查询结果太大，内存都不够用了往磁盘上搬了。
	+ create tmp table 创建临时表，这个要注意
	+ Copying to tmp table on disk 把内存临时表复制到磁盘
	+ locked

复制代码




> 查询中哪些情况不会使用索引？


### 性能优化


#### 索引优化


1. 全值匹配我最爱
2. 最佳左前缀法则，比如建立了一个联合索引(a,b,c)，那么其实我们可利用的索引就有(a), (a,b), (a,b,c)
3. 不在索引列上做任何操作（计算、函数、(自动or手动)类型转换），会导致索引失效而转向全表扫描
4. 存储引擎不能使用索引中范围条件右边的列
5. 尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致))，减少select
6. is null ,is not null 也无法使用索引
7. like "xxxx%" 是可以用到索引的，like "%xxxx" 则不行(like "%xxx%" 同理)。like以通配符开头('%abc...')索引失效会变成全表扫描的操作，
8. 字符串不加单引号索引失效
9. 少用or，用它来连接时会索引失效
10. <，<=，=，>，>=，BETWEEN，IN 可用到索引，<>，not in ，!= 则不行，会导致全表扫描


**一般性建议**


* 对于单键索引，尽量选择针对当前query过滤性更好的索引
* 在选择组合索引的时候，当前Query中过滤性最好的字段在索引字段顺序中，位置越靠前越好。
* 在选择组合索引的时候，尽量选择可以能够包含当前query中的where字句中更多字段的索引
* 尽可能通过分析统计信息和调整query的写法来达到选择合适索引的目的
* 少用Hint强制索引


#### 查询优化


**永远小标驱动大表（小的数据集驱动大的数据集）**

mysql复制代码slect * from A where id in (select id from B)`等价于
#等价于
select id from B
select * from A where A.id=B.id

1 2	当 B 表的数据集必须小于 A 表的数据集时，用 in 优于 exists

mysql复制代码select * from A where exists (select 1 from B where B.id=A.id)
#等价于
select * from A
select * from B where B.id = A.id`


当 A 表的数据集小于B表的数据集时，用 exists优于用 in


注意：A表与B表的ID字段应建立索引。


**order by关键字优化**


* order by子句，尽量使用 Index 方式排序，避免使用 FileSort 方式排序
* MySQL 支持两种方式的排序，FileSort 和 Index，Index效率高，它指 MySQL 扫描索引本身完成排序，FileSort 效率较低；
* ORDER BY 满足两种情况，会使用Index方式排序；①ORDER BY语句使用索引最左前列 ②使用where子句与ORDER BY子句条件列组合满足索引最左前列
* 尽可能在索引列上完成排序操作，遵照索引建的最佳最前缀
* 如果不在索引列上，filesort 有两种算法，mysql就要启动双路排序和单路排序


	+ 双路排序：MySQL 4.1之前是使用双路排序,字面意思就是两次扫描磁盘，最终得到数据
	+ 单路排序：从磁盘读取查询需要的所有列，按照order by 列在 buffer对它们进行排序，然后扫描排序后的列表进行输出，效率高于双路排序
* 优化策略


	+ 增大sort\_buffer\_size参数的设置
	+ 增大max\_lencth\_for\_sort\_data参数的设置


**GROUP BY关键字优化**


* group by实质是先排序后进行分组，遵照索引建的最佳左前缀
* 当无法使用索引列，增大 `max_length_for_sort_data` 参数的设置，增大`sort_buffer_size`参数的设置
* where高于having，能写在where限定的条件就不要去having限定了


#### 数据类型优化


MySQL 支持的数据类型非常多，选择正确的数据类型对于获取高性能至关重要。不管存储哪种类型的数据，下面几个简单的原则都有助于做出更好的选择。


* 更小的通常更好：一般情况下，应该尽量使用可以正确存储数据的最小数据类型。


简单就好：简单的数据类型通常需要更少的CPU周期。例如，整数比字符操作代价更低，因为字符集和校对规则（排序规则）使字符比较比整型比较复杂。
* 尽量避免NULL：通常情况下最好指定列为NOT NULL




---


九、分区、分表、分库
----------


### MySQL分区


一般情况下我们创建的表对应一组存储文件，使用`MyISAM`存储引擎时是一个`.MYI`和`.MYD`文件，使用`Innodb`存储引擎时是一个`.ibd`和`.frm`（表结构）文件。


当数据量较大时（一般千万条记录级别以上），MySQL的性能就会开始下降，这时我们就需要将数据分散到多组存储文件，保证其单个文件的执行效率


**能干嘛**


* 逻辑数据分割
* 提高单一的写和读应用速度
* 提高分区范围读查询的速度
* 分割数据能够有多个不同的物理文件路径
* 高效的保存历史数据


**怎么玩**


首先查看当前数据库是否支持分区


* MySQL5.6以及之前版本：

mysql复制代码SHOW VARIABLES LIKE ‘%partition%’;

1	* MySQL5.6：

mysql复制代码show plugins;



**分区类型及操作**


* **RANGE分区**：基于属于一个给定连续区间的列值，把多行分配给分区。mysql将会根据指定的拆分策略，,把数据放在不同的表文件上。相当于在文件上,被拆成了小块.但是,对外给客户的感觉还是一张表，透明的。


按照 range 来分，就是每个库一段连续的数据，这个一般是按比如**时间范围**来的，比如交易表啊，销售表啊等，可以根据年月来存放数据。可能会产生热点问题，大量的流量都打在最新的数据上了。


range 来分，好处在于说，扩容的时候很简单。
* **LIST分区**：类似于按RANGE分区，每个分区必须明确定义。它们的主要区别在于，LIST分区中每个分区的定义和选择是基于某列的值从属于一个值列表集中的一个值，而RANGE分区是从属于一个连续区间值的集合。
* **HASH分区**：基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算。这个函数可以包含MySQL 中有效的、产生非负整数值的任何表达式。


hash 分发，好处在于说，可以平均分配每个库的数据量和请求压力；坏处在于说扩容起来比较麻烦，会有一个数据迁移的过程，之前的数据需要重新计算 hash 值重新分配到不同的库或表
* **KEY分区**：类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且MySQL服务器提供其自身的哈希函数。必须有一列或多列包含整数值。


**看上去分区表很帅气，为什么大部分互联网还是更多的选择自己分库分表来水平扩展咧？**


* 分区表，分区键设计不太灵活，如果不走分区键，很容易出现全表锁
* 一旦数据并发量上来，如果在分区表实施关联，就是一个灾难
* 自己分库分表，自己掌控业务场景与访问模式，可控。分区表，研发写了一个sql，都不确定mysql是怎么玩的，不太可控



> 随着业务的发展，业务越来越复杂，应用的模块越来越多，总的数据量很大，高并发读写操作均超过单个数据库服务器的处理能力怎么办？


这个时候就出现了**数据分片**，数据分片指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中。数据分片的有效手段就是对关系型数据库进行分库和分表。


区别于分区的是，分区一般都是放在单机里的，用的比较多的是时间范围分区，方便归档。只不过分库分表需要代码实现，分区则是mysql内部实现。分库分表和分区并不冲突，可以结合使用。



> 说说分库与分表的设计


### MySQL分表


分表有两种分割方式，一种垂直拆分，另一种水平拆分。


* **垂直拆分**


垂直分表，通常是按照业务功能的使用频次，把主要的、热门的字段放在一起做为主要表。然后把不常用的，按照各自的业务属性进行聚集，拆分到不同的次要表中；主要表和次要表的关系一般都是一对一的。
* **水平拆分(数据分片)**


单表的容量不超过500W，否则建议水平拆分。是把一个表复制成同样表结构的不同表，然后把数据按照一定的规则划分，分别存储到这些表中，从而保证单表的容量不会太大，提升性能；当然这些结构一样的表，可以放在一个或多个数据库中。


水平分割的几种方法：


    + 使用MD5哈希，做法是对UID进行md5加密，然后取前几位（我们这里取前两位），然后就可以将不同的UID哈希到不同的用户表（user\_xx）中了。
    + 还可根据时间放入不同的表，比如：article\_201601，article\_201602。
    + 按热度拆分，高点击率的词条生成各自的一张表，低热度的词条都放在一张大表里，待低热度的词条达到一定的贴数后，再把低热度的表单独拆分成一张表。
    + 根据ID的值放入对应的表，第一个表user\_0000，第二个100万的用户数据放在第二 个表user\_0001中，随用户增加，直接添加用户表就行了。


![](https://gitee.com/songjianzaina/juejin_p9/raw/master/img/1224fa66c435ca2563dce09a207ff5cd37d9ca5fab8d6759b0171be38caae3c9)


### MySQL分库



> 为什么要分库?


数据库集群环境后都是多台 slave，基本满足了读取操作; 但是写入或者说大数据、频繁的写入操作对master性能影响就比较大，这个时候，单库并不能解决大规模并发写入的问题，所以就会考虑分库。



> 分库是什么？


一个库里表太多了，导致了海量数据，系统性能下降，把原本存储于一个库的表拆分存储到多个库上， 通常是将表按照功能模块、关系密切程度划分出来，部署到不同库上。


优点：


* 减少增量数据写入时的锁对查询的影响
* 由于单表数量下降，常见的查询操作由于减少了需要扫描的记录，使得单表单次查询所需的检索行数变少，减少了磁盘IO，时延变短


但是它无法解决单表数据量太大的问题


**分库分表后的难题**


分布式事务的问题，数据的完整性和一致性问题。


数据操作维度问题：用户、交易、订单各个不同的维度，用户查询维度、产品数据分析维度的不同对比分析角度。 跨库联合查询的问题，可能需要两次查询 跨节点的count、order by、group by以及聚合函数问题，可能需要分别在各个节点上得到结果后在应用程序端进行合并 额外的数据管理负担，如：访问数据表的导航定位 额外的数据运算压力，如：需要在多个节点执行，然后再合并计算程序编码开发难度提升，没有太好的框架解决，更多依赖业务看如何分，如何合，是个难题。



> 配主从，正经公司的话，也不会让 Javaer 去搞的，但还是要知道


十、主从复制
------


### 复制的基本原理


* slave 会从 master 读取 binlog 来进行数据同步
* 三个步骤


    1. master将改变记录到二进制日志（binary log）。这些记录过程叫做二进制日志事件，binary log events；
    2. salve 将 master 的 binary log events 拷贝到它的中继日志（relay log）;
    3. slave 重做中继日志中的事件，将改变应用到自己的数据库中。MySQL 复制是异步且是串行化的。![img](https://gitee.com/songjianzaina/juejin_p9/raw/master/img/75965454cbeb4c4bd6dc89ef0836e0a5f70f9b2249d626c1299f9221ff0793fa)


### 复制的基本原则


* 每个 slave只有一个 master
* 每个 salve只能有一个唯一的服务器 ID
* 每个master可以有多个salve


### 复制的最大问题


* 延时




---


十一、其他问题
-------


### 说一说三个范式


* 第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
* 第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。
* 第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如 果存在"A → B → C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系： 关键字段 → 非关键字段 x → 非关键字段y


### 百万级别或以上的数据如何删除


关于索引：由于索引需要额外的维护成本，因为索引文件是单独存在的文件,所以当我们对数据的增加,修改,删除,都会产生额外的对索引文件的操作,这些操作需要消耗额外的IO,会降低增/改/删的执行效率。所以，在我们删除数据库百万级别数据的时候，查询MySQL官方手册得知删除数据的速度和创建的索引数量是成正比的。


1. 所以我们想要删除百万数据的时候可以先删除索引（此时大概耗时三分多钟）
2. 然后删除其中无用数据（此过程需要不到两分钟）
3. 删除完成后重新创建索引(此时数据较少了)创建索引也非常快，约十分钟左右。
4. 与之前的直接删除绝对是要快速很多，更别说万一删除中断,一切删除会回滚。那更是坑了。


参考与感谢：
------


[zhuanlan.zhihu.com/p/29150809](https://zhuanlan.zhihu.com/p/29150809)


[juejin.im/post/684490…](https://juejin.im/post/6844904061523886088#heading-105)


[blog.csdn.net/yin76783337…](https://blog.csdn.net/yin767833376/article/details/81511377)


![](https://gitee.com/songjianzaina/juejin_p9/raw/master/img/0a7a7e409229c5bc640f7034325b6472a79da3e1fde7000915b8b23e5669956a)



**本文转载自:** [掘金](https://juejin.cn/post/6850037271233331208)

*[开发者博客 – 和开发相关的 这里全都有](https://dev.newban.cn/)*

神奇宝贝眼前一亮的 Jetpack + MVVM 极简实战

发表于 2020-07-14

前言

Jetpack 实战项目 PokemonGo（神奇宝贝）基于 MVVM 架构和 Repository 设计模式，PokemonGo 项目中用到的技术，都是之前写过的一系列文章里面涉及到的知识点：Paging3（network + db），Dagger-Hilt，App Startup，DataBinding，Room，Motionlayout，Kotlin Flow，Coil，JProgressView 等等。

项目 PokemonGo 已经上传到 GitHub: https://github.com/hi-dhl/PokemonGo，欢迎前去查看，动态效果图如下所示，如果动图无法查看，请点击这里查看动态效果图 | 静态图

Jetpack 实战项目 PokemonGo 包含了以下功能：

自定义 RemoteMediator 实现 network + db 的混合使用 ( RemoteMediator 是 Paging3 当中重要成员 )
使用 Data Mapper 分离数据源和 UI
Kotlin Flow 结合 Retrofit2 + Room 的混合使用
Kotlin Flow 与 LiveData 的使用
使用 Coil 加载图片
使用 ViewModel、LiveData、DataBinding 协同工作
使用 Motionlayout 做动画
App Startup 与 Hilt 的使用

PokemonGo 涉及的技术：

Gradle Versions Plugin：检查依赖库是否存在最新版本
Kotlin + Coroutines + Flow：flow 是对 Kotlin 协程的扩展，让我们可以像运行同步代码一样运行异步代码
JetPack
- Paging3（network + db）：用到了 Paging3 中的 RemoteMediator 用来实现 network + db
- Dagger-Hilt (2.28-alpha)：依赖注入框架
- App Startup：设置组件初始化顺序
- DataBinding：以声明方式将可观察数据绑定到界面上
- Room：在 SQLite 上提供了一个抽象层，流畅地访问 SQLite 数据库
- LiveData：在底层数据库更改时通知视图
- ViewModel：以注重生命周期的方式管理界面相关的数据
- Andriod KTX：编写更简洁、惯用的 Kotlin 代码
项目架构
- MVVM 架构
- Repository 设计模式
- Data Mapper 数据映射
Retrofit2 & OkHttp3：用于请求网路数据
Coil：基于 Kotlin 开发的首个图片加载库
material-components-android：模块化和可定制的材料设计 UI 组件
Motionlayout ：MotionLayout 是一种布局类型，可帮助您管理应用中的动画
Timber: 日志打印
JProgressView ：一个小巧灵活可定制的进度条，支持图形：圆形、圆角矩形、矩形等等

以上技术栈对应之前写的技术文章：

如果之前对这些技术没有接触过，或者只是听说，对阅读本文没有什么影响，本文会对这些技术结合着项目 PokemonGo 来分析，为了文章的简洁性，本文不会细究技术细节，因为每个技术都需要花好几篇文章才能分析清楚，我会在后续的文章去详细分析。

如何检查依赖库最新版本

在之前的文章再见吧 buildSrc, 拥抱 Composing builds 提升 Android 编译速度分析过，到目前为止大概管理 Gradle 依赖提供了 4 种不同方法：

手动管理：在每个 module 中定义插件依赖库，每次升级依赖库时都需要手动更改（不建议使用）
使用 ext 的方式管理插件依赖库：这是 Google 推荐管理依赖的方法 Android官方文档
Kotlin + buildSrc：自动补全和单击跳转，依赖更新时 将重新 构建整个项目
Composing builds：自动补全和单击跳转，依赖更新时 不会重新 构建整个项目

新版的 AndroidStudio 只支持 ext 的方式 和 手动方式管理 检查依赖库是否存在最新版本，不支持 buildSrc、gradle-wrapper 版本的检查。

满足不了 PokemonGo 项目的需求，在 PokemonGo 项目中采用 buildSrc 方式去管理所有依赖库，因为 PokemonGo 项目采用单模块结构，而且支持 自动补全 和 单击跳转 很方便，所这里用到了 Gradle Versions Plugin 插件去检查依赖库的最新版本，检查结果如下所示：

less复制代码The following dependencies have later release versions:
 - androidx.swiperefreshlayout:swiperefreshlayout [1.0.0 -> 1.1.0]
     https://developer.android.com/jetpack/androidx
 - com.squareup.okhttp3:logging-interceptor [3.9.0 -> 4.7.2]
     https://square.github.io/okhttp/
 - junit:junit [4.12 -> 4.13]
     http://junit.org
 - org.koin:koin-android [2.1.5 -> 2.1.6]
 - org.koin:koin-androidx-viewmodel [2.1.5 -> 2.1.6]
 - org.koin:koin-core [2.1.5 -> 2.1.6]

Gradle release-candidate updates:
 - Gradle: [6.1.1 -> 6.5.1]

会列出所有需要更新的依赖库的最新版本，并且 Gradle Versions Plugin 比 AndroidStudio 所支持的更加全面：

支持手动方式管理依赖库最新版本检查
支持 ext 的方式管理依赖库最新版本检查
支持 buildSrc 方式管理依赖库最新版本检查
支持 gradle-wrapper 最新版本检查
支持多模块的依赖库最新版本检查

那么如何使用呢？只需要三步

1.将 PokemonGo 项目根目录 checkVersions.gradle 文件拷贝到你的项目根目录下面
2.在项目的根目录 build.gradle 文件夹内添加以下代码

scss复制代码apply from: './checkVersions.gradle'
buildscript {
    repositories {
        google()
        jcenter()
    }
    dependencies {
        classpath "com.github.ben-manes:gradle-versions-plugin:0.28.0"
    }
}

3.添加完成之后，在根目录下执行以下命令。

1	bash复制代码./gradlew dependencyUpdates

会在当前目录下生成 build/dependencyUpdates/report.txt 文件。

MVVM 架构

Jetpack 实战项目 PokemonGo 基于 MVVM 架构和 Repository 设计模式，如今几乎所有的 Android 开发者至少都听过 MVVM 架构，在谷歌 Android 团队宣布了 Jetpack 的视图模型之后，它已经成为了现代 Android 开发模式最流行的架构之一，如下图所示：

MVVM 有助于将应用程序的业务逻辑与 UI 完全分开。如果业务逻辑与 UI 逻辑之间的联系非常紧密，那么维护将很困难，由于很难重用业务逻辑，因此编写单元测试代码非常困难，一堆重复的代码和复杂的逻辑。

Jetpack 的视图模型的 MVVM 架构由 View + DataBinding + ViewModel + Model 组成。

DataBinding

DataBinding（数据绑定）实际上是 XML 布局中的另一个视图结构层次，视图 (XML) 通过数据绑定层不断地与 ViewModel 交互。

我们来看一个例子，首页上有个 RecyclerView 用来展示神奇宝贝数据（名字、图片、点击事件等等），每一个 item 对应一个 ViewHolder，来看一下 ViewHolder 的实现。

kotlin复制代码class PokemonViewModel(view: View) : DataBindingViewHolder<PokemonListModel>(view) {
    private val mBinding: RecycleItemPokemonBinding by viewHolderBinding(view)

    override fun bindData(data: PokemonListModel, position: Int) {
        mBinding.apply {
            pokemon = data
            executePendingBindings()
        }
    }

}

正如你所看到的，由于使用了数据绑定，ViewHolder 里面的代码变的非常简单，可能这个例子不够明显，我们来看一个劲爆的，点击首页每一个 item 会跳转到详情页面，详情页面如下图所示：

device11

详情页面（DetailActivity）展示了神奇宝贝的详细数据，先查询数据库，如果没有找到，读取网路数据然后保存到数据库，由于使用了数据绑定，代码变得非常简单，如下所示：

kotlin复制代码class DetailActivity : DataBindingAppCompatActivity() {

    private val mBindingActivity: ActivityDetailsBinding by binding(R.layout.activity_details)
    private val mViewModel: DetailViewModel by viewModels()
    lateinit var mPokemonModel: PokemonListModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        mBindingActivity.apply {
            mPokemonModel = requireNotNull(intent.getParcelableExtra(KEY_LIST_MODEL))
            pokemonListModel = mPokemonModel
            lifecycleOwner = this@DetailActivity
            viewModel = mViewModel.apply {
                fectchPokemonInfo(mPokemonModel.name)
                    .observe(this@DetailActivity, Observer {})
            }
        }
    }
}

正如你所见 DetailActivity 代码变得非常简单，如果以后我们想要改变网络的 URL、Model、获取或保存数据的方式等等，我们不需要改变 DetailActivity 中的任何代码。

更多关于 DataBinding 的使用请参考我另外一个仓库 JDataBinding：目前已经封装了一系列的组件包含 DataBindingActivity、DataBindingAppCompatActivity、DataBindingFragmentActivity、DataBindingFragment、DataBindingDialog、DataBindingListAdapter、DataBindingViewHolder 等等。

ViewModel

ViewModel 是 MVVM 架构中非常重要的设计，它在 activities 或 fragments 和业务逻辑中起到了非常重要的作用，它不依赖于 UI 组件，使得单元测试更加容易，ViewModel 以生命周期的方式管理界面相关的数据，直到 Activity 被销毁。

LiveData 与 ViewModel 具有很好的协同作用，LiveData 持有从数据源获取到的数据，并且它可以被 DataBinding 组件观察，当 Activity 被销毁时，它将被取消订阅。

而详情页面（DetailActivity) 代码之所以能这么简单得益于 ViewModel、LiveData、DataBinding 协同工作, 我们来看一下 ViewModel 代码。

kotlin复制代码class DetailViewModel @ViewModelInject constructor(
    val polemonRepository: Repository
) : ViewModel() {
    private val _pokemon = MutableLiveData<PokemonInfoModel>()
    val pokemon: LiveData<PokemonInfoModel> = _pokemon

    @OptIn(ExperimentalCoroutinesApi::class)
    fun fectchPokemonInfo(name: String) = liveData<PokemonInfoModel> {
        polemonRepository.featchPokemonInfo(name)
        .collectLatest {
                _pokemon.postValue(it)
                emit(it)
            }
        .......
        // 省略部分代码，
    }

}

activity_details.xml 代码

ini复制代码<layout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools">

    <data>
        <variable
            name="viewModel"
            type="com.hi.dhl.pokemon.ui.detail.DetailViewModel" />

    </data>
    
    ......
    <androidx.appcompat.widget.AppCompatTextView
        android:id="@+id/weight"
        android:text="@{viewModel.pokemon.getWeightString}"/>
    ......
    
</layout>

这是获取神奇宝贝的详细信息，通过 DataBinding 以声明方式将数据（神奇宝贝的体重）绑定到界面上，更多使用参考项目中的代码。

Repository

Repository 设计模式是最流行、应用最广泛的设计模式之一，在 Repository 层获取网络数据，并将数据存储到数据库中，在这一层中有两个非常重要的成员 Paging3 库中的 RemoteMediator 和 Data Mappers。

RemoteMediator

在之前的文章 Jetpack 成员 Paging3 实践以及源码分析（一）和 Jetpack 新成员 Paging3 网络实践及原理分析（二）分别分析了使用 Paging3 访问 数据库 和网络，但是遗漏了 RemoteMediator 类的使用，RemoteMediator 是 Paging3 当中一个非常重要的成员，用于实现 数据库 和网络访问，所以这里是对之前的文章一个补充。

RemoteMediator 很重要，需要单独花一篇文章去分析，为了节省篇幅，在这里不会详细的去分析它，如果对 RemoteMediator 不太理解没有关系，我会在后续的文章里面详细的分析它。

项目中网络访问用的是 Retrofit2 & OkHttp3 用来请求网络数据，使用 Room 作为数据库存储，将获得的数据保存到数据库中，Room 在 SQLite 上提供了一个抽象层，流畅地访问 SQLite 数据库，同时拥有了 SQLite 全部功能，在编译的时候进行错误检查。

kotlin复制代码@OptIn(ExperimentalPagingApi::class)
class PokemonRemoteMediator(
    val api: PokemonService,
    val db: AppDataBase
) : RemoteMediator<Int, PokemonEntity>() {
    val mPageKey = 0
    override suspend fun load(
        loadType: LoadType,
        state: PagingState<Int, PokemonEntity>
    ): MediatorResult {
        try {

            ......
            val pageKey = when (loadType) {
                // 首次访问 或者调用 PagingDataAdapter.refresh()
                LoadType.REFRESH -> null
                // 在当前加载的数据集的开头加载数据时
                LoadType.PREPEND -> return MediatorResult.Success(endOfPaginationReached = true)
                // 在当前数据集末尾添加数据
                LoadType.APPEND -> {
                    ......
                    if (remoteKey == null || remoteKey.nextKey == null) {
                        return MediatorResult.Success(endOfPaginationReached = true)
                    }
                    remoteKey.nextKey
                }
            }

            ......
            // 使用 Retrofit2 获取网络数据
            val page = pageKey ?: 0
            val result = api.fetchPokemonList(
                state.config.pageSize,
                page * state.config.pageSize
            ).results
            

            .......

            db.withTransaction {
                if (loadType == LoadType.REFRESH) { // 当首次加载，或者下拉刷新的时候，清空当前数据 }
                ......
                // 存储获取到的数据
                remoteKeysDao.insertAll(entity)
                pokemonDao.insertPokemon(item)
            }

            return MediatorResult.Success(endOfPaginationReached = endOfPaginationReached)
        } catch (e: IOException) {
            return MediatorResult.Error(e)
        } catch (e: HttpException) {
            return MediatorResult.Error(e)
        }
    }
}

注意：使用了 @OptIn(ExperimentalPagingApi::class) 需要在 App 模块 build.gradle 文件内添加以下代码。

css复制代码android {
    kotlinOptions {
        freeCompilerArgs += ["-Xopt-in=kotlin.RequiresOptIn"]
    }
}

在 RemoteMediator 的实现类 PokemonRemoteMediator 中的核心部分是关于参数 LoadType 的判断。

LoadType.REFRESH：首次访问 或者调用 PagingDataAdapter.refresh() 触发，这里不需要做任何操作，返回 null 就可以
LoadType.PREPEND：在当前列表头部添加数据的时候时触发，实际在项目中基本很少会用到直接返回 MediatorResult.Success(endOfPaginationReached = true) ，参数 endOfPaginationReached 表示没有数据了不在加载
LoadType.APPEND：下拉加载更多时触发，这里获取下一页的 key, 如果 key 不存在，表示已经没有更多数据，直接返回 MediatorResult.Success(endOfPaginationReached = true) 不会在进行网络和数据库的访问

接下来的逻辑和之前请求网络数据的逻辑没有什么区别了，使用 Retrofit2 获取网络数据，然后使用 Room 将数据保存到数据库中。

接下来聊一下 Repository 中另外一个重要的成员 Data Mapper，在项目中起到了非常的重要，在一个快速开发的项目中，为了越快完成第一个版本交付，下意识的将数据源和 UI 绑定到一起，当业务逐渐增多，数据源变化了，上层也要一起变化，导致后期的重构工作量很大，核心的原因耦合性太强了。

Data Mapper（个人建议）

Data Mapper 的意识非常重要，在项目中起到了非常的重要，关于 Data Mappers 在 Repository 中的重要性可以看一下国外大神写的这篇文章 The “Real” Repository Pattern in Android 在 Medium 上获得了 4.9K 的赞。

使用 Data Mapper 分离数据源的 Model 和页面显示的 Model，不要因为数据源的增加、修改或者删除，导致上层页面也要跟着一起修改，换句话说使用 Data Mapper 做一个中间转换，如下图所示，来源于网络：

使用 Data Mapper（数据映射）优点如下：

数据源的更改不会影响上层的业务
糟糕的后端实现不会影响上层的业务 ( 想象一下，如果你被迫执行2个网络请求，因为后端不能在一个请求中提供你需要的所有信息，你会让这个问题影响你的整个代码吗? )
Data Mapper 便于做单元测试，确保不会因为数据源的变化，而影响上层的业务

如果在一个大型项目中直接使用 Data Mapper 会有适得其反的效果，所以需要结合设计模式来完善，这不在本文讨论范围之内，其实在这里我想表达是，不要因为快速实现某个功能，下意识的将数据源的 model 和 UI 绑定在一起。

Data Mappe 实现方式有很多种，可以手动实现，也可以通过引入第三方框架，其中有名框架 modelmapper，在 PokemonGo 项目中是手动实现的。

Kotlin Flow

停止使用 RxJava，尝试一下 Flow，不仅简单而且功能很强大，Retrofit2 和 Room 也都提供了对应的支持。

Flow 库是在 Kotlin Coroutines 1.3.2 发布之后新增的库，也叫做异步流，类似 RxJava 的 Observable，在 PokemonGo 项目中也用到了 Flow。

kotlin复制代码override suspend fun featchPokemonInfo(name: String): Flow<PokemonInfoModel> {
    return flow {
        val pokemonDao = db.pokemonInfoDao()
        var infoModel = pokemonDao.getPokemon(name)
        // 查询数据库是否存在，如果不存在请求网络
        if (infoModel == null) {
            // 网络请求
            val netWorkPokemonInfo = api.fetchPokemonInfo(name)
            ......
            pokemonDao.insertPokemon(infoModel) // 插入更新数据库
        }

        val model = mapper2InfoModel.map(infoModel) // 数据转换
        emit(model)
    }.flowOn(Dispatchers.IO)
}

在这里做了三件事：

查询数据库是否存在，如果不存在请求网络
请求网络获取数据，更新数据库
将数据源的 Model 转换为页面显示的 Model

依赖注入

Hilt、Dagger、Koin 等等都是依赖注入库，使用依赖注入库有以下优点：

依赖注入库会自动释放不再使用的对象，减少资源的过度使用。
在配置 scopes 范围内，可重用依赖项和创建的实例，提高代码的可重用性，减少了很多模板代码。
代码变得更具可读性。
易于构建对象。
编写低耦合代码，更容易测试。

在 PokemonGo 项目中使用的是 Hilt，Hilt 是在 Dagger 基础上进行开发的，减少了在项目中进行手动依赖，Hilt 集成了 Jetpack 库和 Android 框架类，并删除了大部分模板代码，让开发者只需要关注如何进行绑定，同时 Hilt 也继承了 Dagger 优点，编译时正确性、运行时性能、并且得到了 Android Studio 的支持，来看一下 Hilt 与 Room 在一起使用的例子。

kotlin复制代码@Module
@InstallIn(ApplicationComponent::class)
object RoomModule {

    /**
     * @Provides 常用于被 @Module 注解标记类的内部的方法，并提供依赖项对象。
     * @Singleton 提供单例
     */
    @Provides
    @Singleton
    fun provideAppDataBase(application: Application): AppDataBase {
        return Room
            .databaseBuilder(application, AppDataBase::class.java, "dhl.db")
            .fallbackToDestructiveMigration()
            .allowMainThreadQueries()
            .build()
    }
    
    @Singleton
    @Provides
    fun provideTasksRepository(
        db: AppDataBase
    ): Repository {
        return PokemonFactory.makePokemonRepository(db)
    }
}

这里需要用到 @Module 注解，使用 @Module 注解的普通类，在其内部提供 Room 的实例，更多使用可以查看 PokemonGo 项目。

小巧灵活的进度条

神奇宝贝详情页的进度条使用的是 JProgressView ：一个小巧灵活可定制的进度条，支持图形：圆形、圆角矩形、矩形等等，效果如下图所示：

起源于当时想用一个现成的库，但是在网上找了很多，没有一个合适自己的，要不大而全，要不作者好久没更新了，要不不兼容 DataBinding，于是乎就自己封装了一个小巧灵活的进度条，项目长期维护并持续更新，如果有更好的建议欢迎告知我，JProgressView 使用非常的简单，根据自己的需求去配置即可。

ini复制代码<com.hi.dhl.jprogressview.JProgressView
    android:layout_width="match_parent"
    android:layout_height="18dp"
    android:layout_below="@+id/exp"
    android:translationZ="100dp"
    app:maxProgressValue="@{viewModel.pokemon.maxExp}"
    app:progressValue="@{viewModel.pokemon.exp}"
    app:progress_animate_duration="@integer/progress_animate_duration"
    app:progress_color="@color/color_progress_4"
    app:progress_color_background="@color/color_progress_bg"
    app:progress_paint_bg_width="@dimen/circle_stroke_width"
    app:progress_paint_value_width="@dimen/circle_stroke_width"
    app:progress_text_color="@android:color/black"
    app:progress_text_size="@dimen/text_size_12sp"
    app:progress_type="@integer/porgress_tpye_round_rect" />

名称	值类型	默认值	备注
progress_type	integer	圆形：1	矩形：0；矩形：0；矩形：0
progress_animate_duration	integer	2000	动画运行时间
progress_color	color	Color.GRAY	当前进度颜色
progress_color_background	color	Color.GRAY	进度条背景颜色
progress_paint_bg_width	dimen	10	进度条背景画笔的宽度
progress_paint_value_width	dimen	10	当前进度画笔的宽度
progress_text_color	color	Color.BLUE	进度条上的文字的颜色
progress_text_size	dimen	`sp2Px(20f)`	进度条上的文字的大小
progress_text_visible	boolean	默认不显示：false	是否显示文字
progress_value	integer	0	当前进度
progress_value_max	integer	100	当前进度条的最大值

更多关于进度条的使用，查看 JProgressView 仓库，全文到这里就结束了，为了节省篇幅，很多在之前系列文章里面分析过的，这里不在详细分析了，更多技术细节会在后续的系列文章中分析。

正在建立一个最全、最新的 AndroidX Jetpack 相关组件的实战项目以及相关组件原理分析文章，目前已经包含了 App Startup、Paging3、Hilt 等等，正在逐渐增加其他 Jetpack 新成员，仓库持续更新，可以前去查看：AndroidX-Jetpack-Practice, 如果这个仓库对你有帮助，请仓库右上角帮我点个赞。

结语

致力于分享一系列 Android 系统源码、逆向分析、算法、翻译、Jetpack 源码相关的文章，正在努力写出更好的文章，如果这篇文章对你有帮助给个 star，文章中有什么没有写明白的地方，或者有什么更好的建议欢迎留言，欢迎一起来学习，在技术的道路上一起前进。

算法

由于 LeetCode 的题库庞大，每个分类都能筛选出数百道题，由于每个人的精力有限，不可能刷完所有题目，因此我按照经典类型题目去分类、和题目的难易程度去排序。

数据结构：数组、栈、队列、字符串、链表、树……
算法：查找算法、搜索算法、位运算、排序、数学、……

每道题目都会用 Java 和 kotlin 去实现，并且每道题目都有解题思路、时间复杂度和空间复杂度，如果你同我一样喜欢算法、LeetCode，可以关注我 GitHub 上的 LeetCode 题解：Leetcode-Solutions-with-Java-And-Kotlin，一起来学习，期待与你一起成长。

Android 10 源码系列

正在写一系列的 Android 10 源码分析的文章，了解系统源码，不仅有助于分析问题，在面试过程中，对我们也是非常有帮助的，如果你同我一样喜欢研究 Android 源码，可以关注我 GitHub 上的 Android10-Source-Analysis，文章都会同步到这个仓库。

Android 应用系列

精选译文

目前正在整理和翻译一系列精选国外的技术文章，不仅仅是翻译，很多优秀的英文技术文章提供了很好思路和方法，每篇文章都会有译者思考部分，对原文的更加深入的解读，可以关注我 GitHub 上的 Technical-Article-Translation，文章都会同步到这个仓库。

工具系列

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

一道搜狗面试题：IO多路复用中select、poll、epo

发表于 2020-07-14

(1)select==>时间复杂度O(n)

它仅仅知道了，有I/O事件发生了，却并不知道是哪那几个流（可能有一个，多个，甚至全部），我们只能无差别轮询所有流，找出能读出数据，或者写入数据的流，对他们进行操作。所以select具有O(n)的无差别轮询复杂度，同时处理的流越多，无差别轮询时间就越长。

(2)poll==>时间复杂度O(n)

poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，但是它没有最大连接数的限制，原因是它是基于链表来存储的.

(3)epoll==>时间复杂度O(1)

epoll可以理解为event poll，不同于忙轮询和无差别轮询，epoll会把哪个流发生了怎样的I/O事件通知我们。所以我们说epoll实际上是事件驱动（每个事件关联上fd）的，此时我们对这些流的操作都是有意义的。（复杂度降低到了O(1)）

select，poll，epoll都是IO多路复用的机制。I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。

epoll跟select都能提供多路I/O复用的解决方案。在现在的Linux内核里有都能够支持，其中epoll是Linux所特有，而select则应该是POSIX所规定，一般操作系统均有实现

select：

select本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。这样所带来的缺点是：

1、单个进程可监视的fd数量被限制，即能监听端口的大小有限。

一般来说这个数目和系统内存关系很大，具体数目可以cat /proc/sys/fs/file-max察看。32位机默认是1024个。64位机默认是2048.

2、对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低：

当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。

3、需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大

poll：

poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。

它没有最大连接数的限制，原因是它是基于链表来存储的，但是同样有一个缺点：

大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。
poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。

epoll:

epoll有EPOLLLT和EPOLLET两种触发模式，LT是默认的模式，ET是“高速”模式。LT模式下，只要这个fd还有数据可读，每次 epoll_wait都会返回它的事件，提醒用户程序去操作，而在ET（边缘触发）模式中，它只会提示一次，直到下次再有数据流入之前都不会再提示了，无论fd中是否还有数据可读。

所以在ET模式下，read一个fd的时候一定要把它的buffer读光，也就是说一直读到read的返回值小于请求值，或者遇到EAGAIN错误。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。

epoll为什么要有EPOLLET触发模式？

如果采用EPOLLLT模式的话，系统中一旦有大量你不需要读写的就绪文件描述符，它们每次调用epoll_wait都会返回，这样会大大降低处理程序检索自己关心的就绪文件描述符的效率.。而采用EPOLLET这种边沿触发模式的话，当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。

如果这次没有把数据全部读写完(如读写缓冲区太小)，那么下次调用epoll_wait()时，它不会通知你，也就是它只会通知你一次，直到该文件描述符上出现第二次可读写事件才会通知你！！！这种模式比水平触发效率高，系统不会充斥大量你不关心的就绪文件描述符

epoll的优点：

没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）；
效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数；即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll。
内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销。

select、poll、epoll 区别总结：

1、支持一个进程所能打开的最大连接数

select

单个进程所能打开的最大连接数有FD_SETSIZE宏定义，其大小是32个整数的大小（在32位的机器上，大小就是3232，同理64位机器上FD_SETSIZE为3264），当然我们可以对进行修改，然后重新编译内核，但是性能可能会受到影响，这需要进一步的测试。

poll

poll本质上和select没有区别，但是它没有最大连接数的限制，原因是它是基于链表来存储的

epoll

虽然连接数有上限，但是很大，1G内存的机器上可以打开10万左右的连接，2G内存的机器可以打开20万左右的连接

2、FD剧增后带来的IO效率问题

select

因为每次调用时都会对连接进行线性遍历，所以随着FD的增加会造成遍历速度慢的“线性下降性能问题”。

poll

同上

epoll

因为epoll内核中实现是根据每个fd上的callback函数来实现的，只有活跃的socket才会主动调用callback，所以在活跃socket较少的情况下，使用epoll没有前面两者的线性下降的性能问题，但是所有socket都很活跃的情况下，可能会有性能问题。

3、消息传递方式

select

内核需要将消息传递到用户空间，都需要内核拷贝动作

poll

同上

epoll

epoll通过内核和用户空间共享一块内存来实现的。

总结：

综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特点。

1、表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。

2、select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善

今天对这三种IO多路复用进行对比，参考网上和书上面的资料，整理如下：

1、select实现

select的调用过程如下所示：

使用copy_from_user从用户空间拷贝fd_set到内核空间
注册回调函数__pollwait
遍历所有fd，调用其对应的poll方法（对于socket，这个poll方法是sock_poll，sock_poll根据情况会调用到tcp_poll,udp_poll或者datagram_poll） -以tcp_poll为例，其核心实现就是__pollwait，也就是上面注册的回调函数。
__pollwait的主要工作就是把current（当前进程）挂到设备的等待队列中，不同的设备有不同的等待队列，对于tcp_poll来说，其等待队列是sk->sk_sleep（注意把进程挂到等待队列中并不代表进程已经睡眠了）。在设备收到一条消息（网络设备）或填写完文件数据（磁盘设备）后，会唤醒设备等待队列上睡眠的进程，这时current便被唤醒了。
poll方法返回时会返回一个描述读写操作是否就绪的mask掩码，根据这个mask掩码给fd_set赋值。
如果遍历完所有的fd，还没有返回一个可读写的mask掩码，则会调用schedule_timeout是调用select的进程（也就是current）进入睡眠。当设备驱动发生自身资源可读写后，会唤醒其等待队列上睡眠的进程。如果超过一定的超时时间（schedule_timeout指定），还是没人唤醒，则调用select的进程会重新被唤醒获得CPU，进而重新遍历fd，判断有没有就绪的fd。
把fd_set从内核空间拷贝到用户空间。

总结：

select的几大缺点：

每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大
同时每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大
select支持的文件描述符数量太小了，默认是1024

2、poll实现

poll的实现和select非常相似，只是描述fd集合的方式不同，poll使用pollfd结构而不是select的fd_set结构，其他的都差不多,管理多个描述符也是进行轮询，根据描述符的状态进行处理，但是poll没有最大文件描述符数量的限制。

poll和select同样存在一个缺点就是，包含大量文件描述符的数组被整体复制于用户态和内核的地址空间之间，而不论这些文件描述符是否就绪，它的开销随着文件描述符数量的增加而线性增大。

3、epoll

epoll既然是对select和poll的改进，就应该能避免上述的三个缺点。那epoll都是怎么解决的呢？在此之前，我们先看一下epoll和select和poll的调用接口上的不同，select和poll都只提供了一个函数——select或者poll函数。

而epoll提供了三个函数，epoll_create,epoll_ctl和epoll_wait，epoll_create是创建一个epoll句柄；epoll_ctl是注册要监听的事件类型；epoll_wait则是等待事件的产生。

对于第一个缺点，epoll的解决方案在epoll_ctl函数中。每次注册新的事件到epoll句柄中时（在epoll_ctl中指定EPOLL_CTL_ADD），会把所有的fd拷贝进内核，而不是在epoll_wait的时候重复拷贝。epoll保证了每个fd在整个过程中只会拷贝一次。

对于第二个缺点，epoll的解决方案不像select或poll一样每次都把current轮流加入fd对应的设备等待队列中，而只在epoll_ctl时把current挂一遍（这一遍必不可少）并为每个fd指定一个回调函数，当设备就绪，唤醒等待队列上的等待者时，就会调用这个回调函数，而这个回调函数会把就绪的fd加入一个就绪链表）。epoll_wait的工作实际上就是在这个就绪链表中查看有没有就绪的fd（利用schedule_timeout()实现睡一会，判断一会的效果，和select实现中的第7步是类似的）。

对于第三个缺点，epoll没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

总结：

（1）select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。

虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。

（2）select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。

关注微信公众号：松华说，获取更多精彩！

BLOG地址：www.liangsonghua.com

公众号介绍：分享在京东工作的技术感悟，还有JAVA技术和业内最佳实践，大部分都是务实的、能看懂的、可复现的

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

不会用Java Future，我怀疑你泡茶没我快, 又是超长

发表于 2020-07-13

你有一个思想，我有一个思想，我们交换后，一个人就有两个思想

If you can NOT explain it simply, you do NOT understand it well enough

现陆续将Demo代码和技术文章整理在一起 Github实践精选，方便大家阅读查看，本文同样收录在此，觉得不错，还请Star🌟

前言
–

创建线程有几种方式？这个问题的答案应该是可以脱口而出的吧

继承 Thread 类
实现 Runnable 接口

但这两种方式创建的线程是属于”三无产品“：

没有参数
没有返回值
没办法抛出异常

复制代码class MyThread implements Runnable{
   @Override
   public void run() {
      log.info("my thread");
   }
}

Runnable 接口是 JDK1.0 的核心产物

复制代码 /**
 * @since   JDK1.0
 */
@FunctionalInterface
public interface Runnable {
    public abstract void run();
}

用着 “三无产品” 总是有一些弊端，其中没办法拿到返回值是最让人不能忍的，于是 Callable 就诞生了

Callable

又是 Doug Lea 大师，又是 Java 1.5 这个神奇的版本

复制代码 /**
 * @see Executor
 * @since 1.5
 * @author Doug Lea
 * @param <V> the result type of method {@code call}
 */
@FunctionalInterface
public interface Callable<V> {
    
    V call() throws Exception;
}

Callable 是一个泛型接口，里面只有一个 call() 方法，该方法可以返回泛型值 V ，使用起来就像这样：

复制代码Callable<String> callable = () -> {
    // Perform some computation
    Thread.sleep(2000);
    return "Return some result";
};

二者都是函数式接口，里面都仅有一个方法，使用上又是如此相似，除了有无返回值，Runnable 与 Callable 就点差别吗？

Runnable VS Callable

两个接口都是用于多线程执行任务的，但他们还是有很明显的差别的

执行机制

先从执行机制上来看，Runnable 你太清楚了，它既可以用在 Thread 类中，也可以用在 ExecutorService 类中配合线程池的使用；Bu～～～～t， Callable 只能在 ExecutorService 中使用，你翻遍 Thread 类，也找不到Callable 的身影

异常处理

Runnable 接口中的 run 方法签名上没有 throws ，自然也就没办法向上传播受检异常；而 Callable 的 call() 方法签名却有 throws，所以它可以处理受检异常；

所以归纳起来看主要有这几处不同点：

整体差别虽然不大，但是这点差别，却具有重大意义

返回值和处理异常很好理解，另外，在实际工作中，我们通常要使用线程池来管理线程（原因已经在为什么要使用线程池? 中明确说明），所以我们就来看看 ExecutorService 中是如何使用二者的

ExecutorService

先来看一下 ExecutorService 类图

我将上图标记的方法单独放在此处

复制代码void execute(Runnable command);

<T> Future<T> submit(Callable<T> task);
<T> Future<T> submit(Runnable task, T result);
Future<?> submit(Runnable task);

可以看到，使用ExecutorService 的 execute() 方法依旧得不到返回值，而 submit() 方法清一色的返回 Future 类型的返回值

细心的朋友可能已经发现， submit() 方法已经在 CountDownLatch 和 CyclicBarrier 傻傻的分不清楚？文章中多次使用了，只不过我们没有获取其返回值罢了，那么

Future 到底是什么呢？
怎么通过它获取返回值呢？

我们带着这些疑问一点点来看

Future

Future 又是一个接口，里面只有五个方法：

从方法名称上相信你已经能看出这些方法的作用

复制代码// 取消任务
boolean cancel(boolean mayInterruptIfRunning);

// 获取任务执行结果
V get() throws InterruptedException, ExecutionException;

// 获取任务执行结果，带有超时时间限制
V get(long timeout, TimeUnit unit) throws InterruptedException,                             ExecutionException,  TimeoutException;

// 判断任务是否已经取消
boolean isCancelled();

// 判断任务是否已经结束
boolean isDone();

铺垫了这么多，看到这你也许有些乱了，咱们赶紧看一个例子，演示一下几个方法的作用

复制代码@Slf4j
public class FutureAndCallableExample {

   public static void main(String[] args) throws InterruptedException, ExecutionException {
      ExecutorService executorService = Executors.newSingleThreadExecutor();

      // 使用 Callable ，可以获取返回值
      Callable<String> callable = () -> {
         log.info("进入 Callable 的 call 方法");
         // 模拟子线程任务，在此睡眠 2s，
         // 小细节：由于 call 方法会抛出 Exception，这里不用像使用 Runnable 的run 方法那样 try/catch 了
         Thread.sleep(5000);
         return "Hello from Callable";
      };

      log.info("提交 Callable 到线程池");
      Future<String> future = executorService.submit(callable);

      log.info("主线程继续执行");

      log.info("主线程等待获取 Future 结果");
      // Future.get() blocks until the result is available
      String result = future.get();
      log.info("主线程获取到 Future 结果: {}", result);

      executorService.shutdown();
   }
}

程序运行结果如下：

如果你运行上述示例代码，主线程调用 future.get() 方法会阻塞自己，直到子任务完成。我们也可以使用 Future 方法提供的 isDone 方法，它可以用来检查 task 是否已经完成了，我们将上面程序做点小修改：

复制代码// 如果子线程没有结束，则睡眠 1s 重新检查
while(!future.isDone()) {
   System.out.println("Task is still not done...");
   Thread.sleep(1000);
}

来看运行结果：

如果子程序运行时间过长，或者其他原因，我们想 cancel 子程序的运行，则我们可以使用 Future 提供的 cancel 方法，继续对程序做一些修改

复制代码while(!future.isDone()) {
   System.out.println("子线程任务还没有结束...");
   Thread.sleep(1000);

   double elapsedTimeInSec = (System.nanoTime() - startTime)/1000000000.0;

   // 如果程序运行时间大于 1s，则取消子线程的运行
   if(elapsedTimeInSec > 1) {
      future.cancel(true);
   }
}

来看运行结果：

为什么调用 cancel 方法程序会出现 CancellationException 呢？是因为调用 get() 方法时，明确说明了：

调用 get() 方法时，如果计算结果被取消了，则抛出 CancellationException （具体原因，你会在下面的源码分析中看到）

有异常不处理是非常不专业的，所以我们需要进一步修改程序，以更友好的方式处理异常

复制代码// 通过 isCancelled 方法判断程序是否被取消，如果被取消，则打印日志，如果没被取消，则正常调用 get() 方法
if (!future.isCancelled()){
   log.info("子线程任务已完成");
   String result = future.get();
   log.info("主线程获取到 Future 结果: {}", result);
}else {
   log.warn("子线程任务被取消");
}

查看程序运行结果：

相信到这里你已经对 Future 的几个方法有了基本的使用印象，但 Future 是接口，其实使用 ExecutorService.submit() 方法返回的一直都是 Future 的实现类 FutureTask

接下来我们就进入这个核心实现类一探究竟

FutureTask

同样先来看类结构

1
2
3

复制代码public interface RunnableFuture<V> extends Runnable, Future<V> {
    void run();
}

很神奇的一个接口，FutureTask 实现了 RunnableFuture 接口，而 RunnableFuture 接口又分别实现了 Runnable 和 Future 接口，所以可以推断出 FutureTask 具有这两种接口的特性：

有 Runnable 特性，所以可以用在 ExecutorService 中配合线程池使用
有 Future 特性，所以可以从中获取到执行结果

FutureTask源码分析

如果你完整的看过 AQS 相关分析的文章，你也许会发现，阅读 Java 并发工具类源码，我们无非就是要关注以下这三点：

1
2
3

复制代码- 状态 （代码逻辑的主要控制）
- 队列 （等待排队队列）
- CAS （安全的set 值）

脑海中牢记这三点，咱们开始看 FutureTask 源码，看一下它是如何围绕这三点实现相应的逻辑的

文章开头已经提到，实现 Runnable 接口形式创建的线程并不能获取到返回值，而实现 Callable 的才可以，所以 FutureTask 想要获取返回值，必定是和 Callable 有联系的，这个推断一点都没错，从构造方法中就可以看出来：

复制代码public FutureTask(Callable<V> callable) {
    if (callable == null)
        throw new NullPointerException();
    this.callable = callable;
    this.state = NEW;       // ensure visibility of callable
}

即便在 FutureTask 构造方法中传入的是 Runnable 形式的线程，该构造方法也会通过 Executors.callable 工厂方法将其转换为 Callable 类型：

复制代码public FutureTask(Runnable runnable, V result) {
    this.callable = Executors.callable(runnable, result);
    this.state = NEW;       // ensure visibility of callable
}

但是 FutureTask 实现的是 Runnable 接口，也就是只能重写 run() 方法，run() 方法又没有返回值，那问题来了：

FutureTask 是怎样在 run() 方法中获取返回值的？

它将返回值放到哪里了？

get() 方法又是怎样拿到这个返回值的呢？

我们来看一下 run() 方法（关键代码都已标记注释）

复制代码public void run() {
   // 如果状态不是 NEW，说明任务已经执行过或者已经被取消，直接返回
   // 如果状态是 NEW，则尝试把执行线程保存在 runnerOffset（runner字段），如果赋值失败，则直接返回
    if (state != NEW ||
        !UNSAFE.compareAndSwapObject(this, runnerOffset,
                                     null, Thread.currentThread()))
        return;
    try {
       // 获取构造函数传入的 Callable 值
        Callable<V> c = callable;
        if (c != null && state == NEW) {
            V result;
            boolean ran;
            try {
               // 正常调用 Callable 的 call 方法就可以获取到返回值
                result = c.call();
                ran = true;
            } catch (Throwable ex) {
                result = null;
                ran = false;
               // 保存 call 方法抛出的异常
                setException(ex);
            }
            if (ran)
               // 保存 call 方法的执行结果
                set(result);
        }
    } finally {        
        runner = null;       
        int s = state;
       // 如果任务被中断，则执行中断处理
        if (s >= INTERRUPTING)
            handlePossibleCancellationInterrupt(s);
    }
}

run() 方法没有返回值，至于 run() 方法是如何将 call() 方法的返回结果和异常都保存起来的呢？其实非常简单, 就是通过 set(result) 保存正常程序运行结果，或通过 setException(ex) 保存程序异常信息

复制代码/** The result to return or exception to throw from get() */
private Object outcome; // non-volatile, protected by state reads/writes

// 保存异常结果
protected void setException(Throwable t) {
    if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) {
        outcome = t;
        UNSAFE.putOrderedInt(this, stateOffset, EXCEPTIONAL); // final state
        finishCompletion();
    }
}

// 保存正常结果
protected void set(V v) {
  if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) {
    outcome = v;
    UNSAFE.putOrderedInt(this, stateOffset, NORMAL); // final state
    finishCompletion();
  }
}

setException 和 set 方法非常相似，都是将异常或者结果保存在 Object 类型的 outcome 变量中，outcome 是成员变量，就要考虑线程安全，所以他们要通过 CAS方式设置 outcome 变量的值，既然是在 CAS 成功后更改 outcome 的值，这也就是 outcome 没有被 volatile 修饰的原因所在。

保存正常结果值（set方法）与保存异常结果值（setException方法）两个方法代码逻辑，唯一的不同就是 CAS 传入的 state 不同。我们上面提到，state 多数用于控制代码逻辑，FutureTask 也是这样，所以要搞清代码逻辑，我们需要先对 state 的状态变化有所了解

复制代码 /*
 *
 * Possible state transitions:
 * NEW -> COMPLETING -> NORMAL  //执行过程顺利完成
 * NEW -> COMPLETING -> EXCEPTIONAL //执行过程出现异常
 * NEW -> CANCELLED // 执行过程中被取消
 * NEW -> INTERRUPTING -> INTERRUPTED //执行过程中，线程被中断
 */
private volatile int state;
private static final int NEW          = 0;
private static final int COMPLETING   = 1;
private static final int NORMAL       = 2;
private static final int EXCEPTIONAL  = 3;
private static final int CANCELLED    = 4;
private static final int INTERRUPTING = 5;
private static final int INTERRUPTED  = 6;

7种状态，千万别慌，整个状态流转其实只有四种线路

FutureTask 对象被创建出来，state 的状态就是 NEW 状态，从上面的构造函数中你应该已经发现了，四个最终状态 NORMAL ，EXCEPTIONAL ， CANCELLED ， INTERRUPTED 也都很好理解，两个中间状态稍稍有点让人困惑:

COMPLETING: outcome 正在被set 值的时候
INTERRUPTING：通过 cancel(true) 方法正在中断线程的时候

总的来说，这两个中间状态都表示一种瞬时状态，我们将几种状态图形化展示一下：

我们知道了 run() 方法是如何保存结果的，以及知道了将正常结果/异常结果保存到了 outcome 变量里，那就需要看一下 FutureTask 是如何通过 get() 方法获取结果的：

复制代码public V get() throws InterruptedException, ExecutionException {
    int s = state;
   // 如果 state 还没到 set outcome 结果的时候，则调用 awaitDone() 方法阻塞自己
    if (s <= COMPLETING)
        s = awaitDone(false, 0L);
   // 返回结果
    return report(s);
}

awaitDone 方法是 FutureTask 最核心的一个方法

复制代码// get 方法支持超时限制，如果没有传入超时时间，则接受的参数是 false 和 0L
// 有等待就会有队列排队或者可响应中断，从方法签名上看有 InterruptedException，说明该方法这是可以被中断的
private int awaitDone(boolean timed, long nanos)
    throws InterruptedException {
   // 计算等待截止时间
    final long deadline = timed ? System.nanoTime() + nanos : 0L;
    WaitNode q = null;
    boolean queued = false;
    for (;;) {
       // 如果当前线程被中断，如果是，则在等待对立中删除该节点，并抛出 InterruptedException
        if (Thread.interrupted()) {
            removeWaiter(q);
            throw new InterruptedException();
        }

        int s = state;
       // 状态大于 COMPLETING 说明已经达到某个最终状态（正常结束/异常结束/取消）
       // 把 thread 只为空，并返回结果
        if (s > COMPLETING) {
            if (q != null)
                q.thread = null;
            return s;
        }
       // 如果是COMPLETING 状态（中间状态），表示任务已结束，但 outcome 赋值还没结束，这时主动让出执行权，让其他线程优先执行（只是发出这个信号，至于是否别的线程执行一定会执行可是不一定的）
        else if (s == COMPLETING) // cannot time out yet
            Thread.yield();
       // 等待节点为空
        else if (q == null)
           // 将当前线程构造节点
            q = new WaitNode();
       // 如果还没有入队列，则把当前节点加入waiters首节点并替换原来waiters
        else if (!queued)
            queued = UNSAFE.compareAndSwapObject(this, waitersOffset,
                                                 q.next = waiters, q);
       // 如果设置超时时间
        else if (timed) {
            nanos = deadline - System.nanoTime();
           // 时间到，则不再等待结果
            if (nanos <= 0L) {
                removeWaiter(q);
                return state;
            }
           // 阻塞等待特定时间
            LockSupport.parkNanos(this, nanos);
        }
        else
           // 挂起当前线程，知道被其他线程唤醒
            LockSupport.park(this);
    }
}

总的来说，进入这个方法，通常会经历三轮循环

第一轮for循环，执行的逻辑是 q == null, 这时候会新建一个节点 q, 第一轮循环结束。
第二轮for循环，执行的逻辑是 !queue，这个时候会把第一轮循环中生成的节点的 next 指针指向waiters，然后CAS的把节点q 替换waiters, 也就是把新生成的节点添加到waiters 中的首节点。如果替换成功，queued=true。第二轮循环结束。
第三轮for循环，进行阻塞等待。要么阻塞特定时间，要么一直阻塞知道被其他线程唤醒。

对于第二轮循环，大家可能稍稍有点迷糊，我们前面说过，有阻塞，就会排队，有排队自然就有队列，FutureTask 内部同样维护了一个队列

1 2	复制代码/** Treiber stack of waiting threads */ private volatile WaitNode waiters;

说是等待队列，其实就是一个 Treiber 类型 stack，既然是 stack，那就像手枪的弹夹一样（脑补一下子弹放入弹夹的情形），后进先出，所以刚刚说的第二轮循环，会把新生成的节点添加到 waiters stack 的首节点

如果程序运行正常，通常调用 get() 方法，会将当前线程挂起，那谁来唤醒呢？自然是 run() 方法运行完会唤醒，设置返回结果（set方法）/异常的方法(setException方法) 两个方法中都会调用 finishCompletion 方法，该方法就会唤醒等待队列中的线程

复制代码private void finishCompletion() {
    // assert state > COMPLETING;
    for (WaitNode q; (q = waiters) != null;) {
        if (UNSAFE.compareAndSwapObject(this, waitersOffset, q, null)) {
            for (;;) {
                Thread t = q.thread;
                if (t != null) {
                    q.thread = null;
                   // 唤醒等待队列中的线程
                    LockSupport.unpark(t);
                }
                WaitNode next = q.next;
                if (next == null)
                    break;
                q.next = null; // unlink to help gc
                q = next;
            }
            break;
        }
    }

    done();

    callable = null;        // to reduce footprint
}

将一个任务的状态设置成终止态只有三种方法：

set
setException
cancel

前两种方法已经分析完，接下来我们就看一下 cancel 方法

查看 Future cancel()，该方法注释上明确说明三种 cancel 操作一定失败的情形

任务已经执行完成了
任务已经被取消过了
任务因为某种原因不能被取消

其它情况下，cancel操作将返回true。值得注意的是，cancel操作返回 true 并不代表任务真的就是被取消, 这取决于发动cancel状态时，任务所处的状态

如果发起cancel时任务还没有开始运行，则随后任务就不会被执行；
如果发起cancel时任务已经在运行了，则这时就需要看 mayInterruptIfRunning 参数了：
- 如果mayInterruptIfRunning 为true, 则当前在执行的任务会被中断
- 如果mayInterruptIfRunning 为false, 则可以允许正在执行的任务继续运行，直到它执行完

有了这些铺垫，看一下 cancel 代码的逻辑就秒懂了

复制代码public boolean cancel(boolean mayInterruptIfRunning) {
  
    if (!(state == NEW &&
          UNSAFE.compareAndSwapInt(this, stateOffset, NEW,
              mayInterruptIfRunning ? INTERRUPTING : CANCELLED)))
        return false;
    try {    // in case call to interrupt throws exception
       // 需要中断任务执行线程
        if (mayInterruptIfRunning) {
            try {
                Thread t = runner;
               // 中断线程
                if (t != null)
                    t.interrupt();
            } finally { // final state
               // 修改为最终状态 INTERRUPTED
                UNSAFE.putOrderedInt(this, stateOffset, INTERRUPTED);
            }
        }
    } finally {
       // 唤醒等待中的线程
        finishCompletion();
    }
    return true;
}

核心方法终于分析完了，到这咱们喝口茶休息一下吧

我是想说，使用 FutureTask 来演练烧水泡茶经典程序

如上图：

洗水壶 1 分钟
烧开水 15 分钟
洗茶壶 1 分钟
洗茶杯 1 分钟
拿茶叶 2 分钟

最终泡茶

让我心算一下，如果串行总共需要 20 分钟，但很显然在烧开水期间，我们可以洗茶壶/洗茶杯/拿茶叶

这样总共需要 16 分钟，节约了 4分钟时间，烧水泡茶尚且如此，在现在高并发的时代，4分钟可以做的事太多了，学会使用 Future 优化程序是必然（其实优化程序就是寻找关键路径，关键路径找到了，非关键路径的任务通常就可以和关键路径的内容并行执行了）

复制代码@Slf4j
public class MakeTeaExample {

   public static void main(String[] args) throws ExecutionException, InterruptedException {
      ExecutorService executorService = Executors.newFixedThreadPool(2);

      // 创建线程1的FutureTask
      FutureTask<String> ft1 = new FutureTask<String>(new T1Task());
      // 创建线程2的FutureTask
      FutureTask<String> ft2 = new FutureTask<String>(new T2Task());

      executorService.submit(ft1);
      executorService.submit(ft2);

      log.info(ft1.get() + ft2.get());
      log.info("开始泡茶");

      executorService.shutdown();
   }

   static class T1Task implements Callable<String> {

      @Override
      public String call() throws Exception {
         log.info("T1:洗水壶...");
         TimeUnit.SECONDS.sleep(1);

         log.info("T1:烧开水...");
         TimeUnit.SECONDS.sleep(15);

         return "T1:开水已备好";
      }
   }

   static class T2Task implements Callable<String> {
      @Override
      public String call() throws Exception {
         log.info("T2:洗茶壶...");
         TimeUnit.SECONDS.sleep(1);

         log.info("T2:洗茶杯...");
         TimeUnit.SECONDS.sleep(2);

         log.info("T2:拿茶叶...");
         TimeUnit.SECONDS.sleep(1);
         return "T2:福鼎白茶拿到了";
      }
   }
}

上面的程序是主线程等待两个 FutureTask 的执行结果，线程1 烧开水时间更长，线程1希望在水烧开的那一刹那就可以拿到茶叶直接泡茶，怎么半呢？

那只需要在线程 1 的FutureTask 中获取线程 2 FutureTask 的返回结果就可以了，我们稍稍修改一下程序：

复制代码@Slf4j
public class MakeTeaExample1 {

   public static void main(String[] args) throws ExecutionException, InterruptedException {
      ExecutorService executorService = Executors.newFixedThreadPool(2);

      // 创建线程2的FutureTask
      FutureTask<String> ft2 = new FutureTask<String>(new T2Task());
      // 创建线程1的FutureTask
      FutureTask<String> ft1 = new FutureTask<String>(new T1Task(ft2));
      
      executorService.submit(ft1);
      executorService.submit(ft2);

      executorService.shutdown();
   }

   static class T1Task implements Callable<String> {

      private FutureTask<String> ft2;
      public T1Task(FutureTask<String> ft2) {
         this.ft2 = ft2;
      }

      @Override
      public String call() throws Exception {
         log.info("T1:洗水壶...");
         TimeUnit.SECONDS.sleep(1);

         log.info("T1:烧开水...");
         TimeUnit.SECONDS.sleep(15);

         String t2Result = ft2.get();
         log.info("T1 拿到T2的 {}， 开始泡茶", t2Result);
         return "T1: 上茶！！！";
      }
   }

   static class T2Task implements Callable<String> {
      @Override
      public String call() throws Exception {
         log.info("T2:洗茶壶...");
         TimeUnit.SECONDS.sleep(1);

         log.info("T2:洗茶杯...");
         TimeUnit.SECONDS.sleep(2);

         log.info("T2:拿茶叶...");
         TimeUnit.SECONDS.sleep(1);
         return "福鼎白茶";
      }
   }
}

来看程序运行结果：

知道这个变化后我们再回头看 ExecutorService 的三个 submit 方法：

1
2
3

复制代码<T> Future<T> submit(Runnable task, T result);
Future<?> submit(Runnable task);
<T> Future<T> submit(Callable<T> task);

第一种方法，逐层代码查看到这里：

你会发现，和我们改造烧水泡茶的程序思维是相似的，可以传进去一个 result，result 相当于主线程和子线程之间的桥梁，通过它主子线程可以共享数据

第二个方法参数是 Runnable 类型参数，即便调用 get() 方法也是返回 null，所以仅是可以用来断言任务已经结束了，类似 Thread.join()

第三个方法参数是 Callable 类型参数，通过get() 方法可以明确获取 call() 方法的返回值

到这里，关于 Future 的整块讲解就结束了，还是需要简单消化一下的

总结
–

如果熟悉 Javascript 的朋友，Future 的特性和 Javascript 的 Promise 是类似的，私下开玩笑通常将其比喻成男朋友的承诺

回归到Java，我们从 JDK 的演变历史，谈及 Callable 的诞生，它弥补了 Runnable 没有返回值的空缺，通过简单的 demo 了解 Callable 与 Future 的使用。 FutureTask 又是 Future接口的核心实现类，通过阅读源码了解了整个实现逻辑，最后结合FutureTask 和线程池演示烧水泡茶程序，相信到这里，你已经可以轻松获取线程结果了

烧水泡茶是非常简单的，如果更复杂业务逻辑，以这种方式使用 Future 必定会带来很大的会乱（程序结束没办法主动通知，Future 的链接和整合都需要手动操作）为了解决这个短板，没错，又是那个男人 Doug Lea, CompletableFuture 工具类在 Java1.8 的版本出现了，搭配 Lambda 的使用，让我们编写异步程序也像写串行代码那样简单，纵享丝滑

接下来我们就了解一下 CompletableFuture 的使用

灵魂追问

你在日常开发工作中是怎样将整块任务做到分工与协作的呢？有什么基本准则吗？
如何批量的执行异步任务呢？

参考

Java 并发编程实战
Java 并发编程的艺术
Java 并发编程之美

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

前言

介绍

什么时候进行减库存

解决办法

如何安全的减库存

综上所述：

订单与库存涉及的几个重要知识

写在最后的话

Spring之AOP

什么是AOP？

作用及其优势

AOP 的底层实现

AOP 的动态代理技术

JDK 的动态代理

cglib 的动态代理

相关知识要点

基于XML配置文件的AOP开发

XML 配置 AOP 详解

1) 切点表达式的写法

2) 通知的类型

3) 切点表达式的抽取

基于注解的 AOP 开发

注解配置 AOP 详解

1) 注解通知的类型

2) 切点表达式的抽取

知识要点

最后

一、实现原理

二、实现方式

三、FastClass机制

1.1 什么是lambda

1.2 java为什么要引入lambda

1.3 如何使用lambda表达式

1.4 lambda表达式方法引用，构造器引用和数组引用

构造器引用

2.1 什么是Stream

2.2 常用api

1. Arrays.stream()

2. Stream.of()

3. Collection.stream()

4.filter

5.map

6.flatMap

7.limit方法和skip方法

8.distinct方法和sorted方法

9.Collect

10.聚合操作

11.分组

2.3 Stream流的处理顺序

2.4 并行流

最后

一、授权流程

二、身份注册

三、授权开发

1、获取授权码

2、获取令牌

总结

一、Activity切换过渡动画

一)、共享元素过渡动画

二)、进入过渡与退出过渡动画

三)、兼容Android 5.0前

二、布局变化过渡动画

一)、手动创建Scene

二)、系统自动创建Scene

三、过渡动画效果

一)、内置过渡动画

二)、自定义过渡动画

一、MySQL架构

二、存储引擎

查看存储引擎

设置存储引擎

存储引擎对比

文件存储结构对比

面试这么回答

三、数据类型

四、索引

基本语法：

优势

劣势

MySQL索引分类

性能下降SQL慢执行时间长等待时间长原因分析