整理

面试 技术

基础

面向对象三大特性

继承、封装、多态

重写 equals() 时必须重写 hashCode() ？

Object 类的 equals() 方法比较的是对象的地址，hashCode() 是根据内存地址算出来的。同一个对象hashCode必须相同，hashCode相同不一定是同一个对象。
如果重写equals的时候没有重写hashCode，会违反Object.hashCode的通用约定，导致该类无法结合所有基于散列的集合一起工作，包括HashMap、HashSet、HashTable等。

正例：对象放入 HashSet 时，先计算对象的 hashcode 判断对象放入位置，与已经放入对象的 hashcode 比较，如果没有相同的，HashSet 会假设对象没有重复出现。如果有相同的，会再调用 equals() 是否真的相等，如果相等，HashSet 不会让其加入成功；如果不同，会重新散列到其他位置，大大减少了equals 的次数，提高速度。

反例：都不重写，new 两个Person 对象，都叫张三，hashCode()和equals()判断不同；重写一个同样不行。

hashCode()应该怎样重写？

// String的hashCode()
public int hashCode() {
    int h = hash; //hash初始值为0
    if (h == 0 && value.length > 0) {
        char val[] = value;
        for (int i = 0; i < value.length; i++) {
            h = 31 * h + val[i];//31是质数，不大不小，避免溢出
        }
        hash = h;
    }
    return h;
}

可以参考Objects类中计算hashCode的逻辑

public static int hashCode(Object o) {
    return o != null ? o.hashCode() : 0;
}
public static int hash(Object... values) {
    return Arrays.hashCode(values);
}
public static int hashCode(Object a[]) {
    if (a == null)
        return 0;
    int result = 1;
    for (Object element : a)
        //31是质数，不大不小，避免溢出
        result = 31 * result + (element == null ? 0 : element.hashCode());
    return result;
}

String为什么被设计为不可变的？

• String类型是使用最多，每次增删改差之前其实jvm需要通过hashcode检查对象的安全性，设计成不可变对象，保证了每次增删改查的hashcode的唯一性。
• 网络连接地址URL,文件路径path通常情况下都是以String类型保存, 假若String不是固定不变的,将会引起各种安全隐患。
• 字符串值是被保留在常量池中的，假如字符串对象允许改变,那么将会导致各种逻辑错误

HashMap的时间复杂度？Hash冲突是怎么解决的？Java8中的HashMap有什么变化？

理想情况下O(1)，最坏O(n)，平均O(1)。

解决 Hash 冲突使用链表法，链表过长时性能会下降。

Java 8中 HashMap 的变化：

1. 引入红黑树：当链表长度超过阈值时，链表会转为红黑树，提高查找效率。
2. 使用尾插法：避免并发环境下可能出现的死循环问题。
3. 扩容机制优化

红黑树是依据什么进行比较大小的？其他Hash冲突解决方式？

依据Key(必须可比较)，Key 相等可能会比较节点的哈希值。

其他解决哈希冲突的方法：开放寻址法、再哈希法。

ConcurrentHashMap的Key为何不能为null？

1. 源码中有校验，如果key或者value为null，会抛出NullPointerException。
2. 从设计上说，为了防止并发场景下的歧义问题。比如 get 方法取值，不确定是key不存在，还是value本来就是 null，并发场景下有可能被别的线程修改。

HashMap可以存储 null的 key 和 value，但 null 作为key只能有一个，作为值可以有多个。null 作为 key，会返回 hash 为0位置的值，单线程环境下不存在歧义问题。

参考：ConcurrentHashMap为什么key和value不能为null

Spring事务失效的12种场景

Spring 事务：再对应service层方法上使用@Transcational，分布式的话需使用分布式事务。下面几种情况会导致事务不生效

• 访问权限不是 public

• 方法用 final 修饰/是static
  spring 事务底层通过 jdk 动态代理/cglib，帮我们生成代理类，在代理类中实现事务功能；如果某个方法用 final 修饰/是static，在它的代理类中就无法重写该方法

• 同一个类中的方法内部调用

  • 如果确实有场景要保证事务，可以直接注入自己，Spring 的三级缓存保证了不会出现循环依赖的问题
  • 不要直接内部调用，使用 AopContext.currentProxy() 获取代理对象，再调用

• 未被 Spring 管理

• 多线程调用（不同的线程拿到的数据库连接不同，事务必然失效）

• 表不支持事务（比如使用 MyISAM）

• 未开启事务

下面几种情况会导致事务不回滚

• 错误的传播特性
  默认的传播特性REQUIRED：如果当前上下文中存在事务，则加入该事务，如果不存在，则创建一个事务。只有这三种传播特性才会创建新事务：REQUIRED，REQUIRES_NEW，NESTED
• 自己吞异常
• 手动抛了别的异常
  spring 事务默认情况下只会滚RuntimeException（运行时异常）和Error（错误），对于普通的 Exception（非运行时异常）不会回滚
• 自定义了回滚异常
  抛出的异常不属于 rollbackFor 设置的异常，则事务不会回滚，一般建议设置为 Exception
• 嵌套事务多回滚了
  即：只想回滚嵌套事务（propagation=Propagation.NESTED），但将整个事务都回滚了，如何处理？使用 try……catch 包住嵌套事务内的异常不往外抛

其他

大事务问题：事务执行耗时比较长，会导致死锁、锁等待、回滚时间长、接口超时、并发情况下数据库连接被占满、数据库主从延迟等问题

编程式事务，基于TransactionTemplate的编程式事务优点：避免由于 Spring AOP 导致事务失效的问题、能更小粒度的控制事务的范围，更直观

    @Autowired
    private TransactionTemplate transactionTemplate;
    public void save(final User user) {
        queryData1();
        queryData2();
        transactionTemplate.execute((status) => {
            addData1();
            updateData2();
            return Boolean.TRUE;
        })
    }

Spring的三级缓存机制

三级缓存分别是：
singletonObject：一级缓存，该缓存 key=beanName, value=bean；该 bean 是已经创建完成的，经历过实例化->属性填充->初始化以及各类的后置处理。一旦需要获取 bean 时，第一时间就会寻找一级缓存；
earlySingletonObjects：二级缓存，该缓存 key = beanName, value = bean；跟一级缓存的区别在于，该缓存所获取到的 bean 是提前曝光出来的，还没创建完成。获取到的 bean 只能确保已进行了实例化，但是属性填充跟初始化肯定还没有做完，因此该 bean 还没创建完成，仅仅能作为指针提前曝光，被其他 bean 所引用；
singletonFactories：三级缓存，该缓存 key = beanName, value = beanFactory；在 bean 实例化完之后，属性填充、初始化之前，如果允许提前曝光，spring 会将实例化后的 bean 提前曝光，也就是把该 bean 转换成 beanFactory 并加入到三级缓存。在需要引用提前曝光对象时再通过 singletonFactory.getObject() 获取。

具体参考当Spring AOP遇上循环依赖

Spring Event

Spring Event 使用观察者模式，事件源发布一个事件，事件监听器可以消费这个事件，事件源不用关注发布的事件有哪些监听器，可以对系统进行解耦。实现方式上有两种：

• 类实现ApplicationListener接口
• 方法上使用@EventListener注解

Spring 中事件监听器的处理默认是同步方式，可以改为异步，有两种方式

• 注入名称为applicationEventMulticaster的bean，顺便给executor设置一个值，就可以实现监听器异步执行了
• 监听方法上使用 @Async注解

Spring 事件监听器消费事件同步模式下支持自定义顺序，一般在监听方法上使用@Order(1)，数字越小优先级越高；异步模式下顺序不靠谱。
适用场景：异步模式将主逻辑和监听器逻辑分到不同线程中，适合非主要逻辑，因为监听器运行有可能失败。如果非主要逻辑要求必须成功，考虑使用更重量级的消息中间件来解决。
具体代码参考：@EventListener：定义 spring 事件监听器

SOA和微服务的区别？

多线程

线程池的有哪些参数？

• corePoolSize：核心线程数。当线程池中线程数 < corePoolSize 时，默认是添加一个任务才创建一个线程池；当线程数 = corePoolSize 时，新任务会追加到工作队列(workQueue)中。

• maximumPoolSize：允许的最大线程数（非核心线程数 + 核心线程数）。当工作队列也满了，线程池中总线程数 < maximumPoolSize 时就会增加线程数量。

• keepAliveTime：非核心线程（maximumPoolSize - corePoolSize）闲置下来的最多存活时间。

• unit：线程池中非核心线程存活时间的单位

• workQueue：线程池等待队列，维护着等待执行的 Runnable 对象。当运行线程数 = corePoolSize 时，新的任务会被添加到 workQueue 中，如果 workQueue 也满了，则尝试用非核心线程执行任务，等待队列应该尽量用有界的。常用的阻塞队列：

  • ArrayBlockingQueue：数组实现的有界队列
  • LinkedBlockingQueue：基于链表实现的阻塞队列，容量不设置的话将是一个无界队列，最大长度 Integer.MAX_VALUE，吞吐量比 ArrayBlockingQueue 高。
  • DelayQueue：延迟队列，根据指定的执行时间从小到大排序，否则根据插入到队列的先后排序
  • PriorityBlockingQueue：具有优先级的无界阻塞队列。
  • SynchronousQueue：不存储元素的阻塞队列，吞吐量高于 LinkedBlockingQueue

• threadFactory：创建新线程时的工厂，可以用来设定线程名、是否为守护线程等。

• handler：corePoolSize、workQueue、maximumPoolSize 都不可用的时候执行的拒绝策略。

  • AbortPolicy：直接抛出异常，默认使用此策略；
  • CallerRunsPolicy：由调用者所在的线程来执行任务；
  • DiscardOldestPolicy：丢弃阻塞队列里最老的任务
  • DiscardPolicy：当前任务直接丢弃
  • 写自己的拒绝策略，需实现 RejectedExecutionHandler 接口即可；

线程池的执行流程？

1. 线程池刚创建时，里面没有线程，任务队列作为参数传进来

2. 当调用 execute() 方法添加一个任务时，线程池会判断：

   • 运行的线程数量 < corePoolSize，则创建线程运行此任务
   • 运行的线程数量 >= corePoolSize，那么这个任务将放入队列
     
     • 队列已满 & 运行的线程数 < maximumPoolSize，则创建非核心线程运行此任务
     • 队列已满 & 运行的线程数 >= maximumPoolSize，则根据拒绝策略来处理

3. 当线程完成任务时，会从队列中取一个任务来执行

4. 当前运行的线程数大于 corePoolSize，线程空闲超过一定时间（keepAliveTime）时，那么这个线程就会被停掉。线程池所有任务完成后，线程数最终会收缩到 corePoolSize 的大小。

线程池的线程数如何配置？

• 计算密集型：CPU数 + 1
• IO 密集型：CPU核心数 * 2
• 混合型：根据情况拆分为 CPU 密集型和 IO 密集型

具体参考 Java线程池实现原理及其在美团业务中的实践

线程池中线程抛异常了，如何处理？

public class ThreadPoolException {
    public static void main(String[] args) {
        //创建一个线程池
        ExecutorService executorService=Executors.newFixedThreadPool(1);
        //当线程池抛出异常后submit无提示，其他线程继续执行
        executorService.submit(new task());
        //当线程池抛出异常后execute抛出异常，其他线程继续执行新任务
        executorService.execute(new task());
    }
}
//任务类
class task implements Runnable{
    @Override
    public void run() {
        System.out.println("进入了task方法！！！");
        int i=1/0;
    }
}

任务提交方式中，execute会打印异常信息，submit不打印异常，要想获取异常信息就必须使用get()

//当线程池抛出异常后submit无提示，其他线程继续执行
Future<?> submit = executorService.submit(new task());
submit.get();

方案一：使用try-catch
方案二：使用Thread.setDefaultUncaughtExceptionHandler方法捕获异常。
重写线程工厂方法，在线程工厂创建线程的时候，赋予UncaughtExceptionHandler处理器对象
方案三：重写afterExecute进行异常处理

public class ThreadPoolException3 {
    public static void main(String[] args) throws InterruptedException,ExecutionException {
        //1.创建一个自己定义的线程池
        ExecutorService executorService = new ThreadPoolExecutor(2,3,0,TimeUnit.MILLISECONDS,new LinkedBlockingQueue(10)) {
            //重写afterExecute方法
            @Override
            protected void afterExecute(Runnable r, Throwable t) {
                //这个是excute提交的时候
                if (t != null) {
                    System.out.println("获取到excute提交的异常信息，处理异常"+t.getMessage());
                }
                //如果r的实际类型是FutureTask那么是submit提交的，所以可以在里面get到异常
                if (r instanceof FutureTask) {
                    try {
                        Future<?> future = (Future<?>) r;
                        //get获取异常
                        future.get();
                    } catch (Exception e) {
                        System.out.println("获取到submit提交的异常信息，处理异常" + e);
                    }
                }
            }
        };
        //当线程池抛出异常后execute
        executorService.execute(new task());
        //当线程池抛出异常后submit
        executorService.submit(new task());
    }
}
class task3 implements Runnable {
    @Override
    public void run() {
        System.out.println("进入了task方法！！！");
        int i = 1 / 0;
    }
}

从线程池角度考虑如何减少任务的阻塞时间？

• 思路一：根据具体的使用场景配置合理的线程池参数，参考上一个问题/不断压测调整到最优参数
• 思路二：任务到来后先增加核心线程，达到核心线程数后任务被放到阻塞队列中，阻塞队列满后才会继续创建非核心线程达到最大线程数。可以通过修改阻塞队列的实现，当任务超过核心线程数后，直接创建非核心线程而不是将任务放入阻塞队列，以减少任务的阻塞时间

多线程的业务场景

1. 简单定时任务
   new Thread 里面放一个 while(true) 循环。优点是简单，缺点是功能单一，无法应对复杂场景

2. 监听器
   搭配配置中心，修改配置开关后，动态刷新，服务端用开关判断是否启动业务逻辑处理

3. 收集日志
   如果没有引入 MQ，可以通过多个线程/线程池异步写日志数据到数据库

4. excel导入
   excel 导入读取数据后可能有复杂的业务逻辑需要处理，可以通过多线程处理。最简单的实现方式：parallelStream，它通过ForkJoinPool实现

5. 统计数量
   count++ 并非原子操作，多线程执行时，统计次数可能出现异常。可以使用AtomicInteger等atomic包下面的类

6. 查询接口
   接口中有串行远程调用的，可以改为并行调用

public UserInfo getUserInfo(Long id) throws InterruptedException, ExecutionException {
    final UserInfo userInfo = new UserInfo();
    CompletableFuture userFuture = CompletableFuture.supplyAsync(() -> {
        getRemoteUserAndFill(id, userInfo);
        return Boolean.TRUE;
    }, executor);
    CompletableFuture bonusFuture = CompletableFuture.supplyAsync(() -> {
        getRemoteBonusAndFill(id, userInfo);
        return Boolean.TRUE;
    }, executor);
    CompletableFuture growthFuture = CompletableFuture.supplyAsync(() -> {
        getRemoteGrowthAndFill(id, userInfo);
        return Boolean.TRUE;
    }, executor);
    CompletableFuture.allOf(userFuture, bonusFuture, growthFuture).join();
    userFuture.get();
    bonusFuture.get();
    growthFuture.get();
    return userInfo;
}

并发

ThreadLocal 原理？

ThreadLocal 是线程本地变量，存放每个线程的私有数据。

每个线程都有一个 ThreadLocalMap，维护一个 Entry[]，数组元素的Key是 ThreadLocal 对象，value是线程对应的数据。使用线性探测解决 hash 冲突，需要手动调用 set、get、remove 防止内存泄漏。

使用场景：

• 作为数据副本
• 保存线程上下文，在需要的地方获取
• 解决线程安全问题

ThreadLocal 内存泄漏的原因？

每个线程都有一个 ThreadLocalMap 的内部属性，map 的 key 是 ThreadLocal 且是弱引用，value 是强引用。垃圾回收时会自动回收 key，value的回收取决于线程对象的生命周期。线程池中的线程长时间存货，value 释放不掉导致内存泄露。

知道哪些锁，每个锁的原理是什么？多线程下的锁有哪些？MySQL层面的锁？

锁是一种并发控制机制，用于在多线程/进程环境下，控制对共享资源的访问，从而保证数据的一致性和完整性。

多线程下的锁（JVM层面）

• synchronized（监视器锁）
  
  • 原理：基于JVM内置的监视器机制。修饰代码块时，通过monitorenter和monitorexit指令实现；修饰方法时由方法控制位ACC_SYNCHRONIZED控制。
  • 特点：隐式加解锁、不可中断、非公平、自动释放、锁升级优化。
• ReentrantLock（可重入锁）
  
  • 原理：基于AQS抽象队列同步器，维护一个state变量表示锁的获取次数，并记录当前持有锁的线程。
  • 特点：显式加解锁、可重入、支持公平和非公平锁、支持中断、超时，可绑定多个条件变量。
• ReadWriteLock（读写锁）
  
  • 原理：基于AQS，内部维护一个读锁一个写锁，写独占，都共享。
  • 特点：适用于读多写少场景，能显著提高并发性能。
• StampedLock（邮戳锁）
  
  • 原理：支持写锁、悲观读、乐观读三种模式。
  • 特点：性能高，使用复杂，不支持可重入。
• Atomic系列的类（原子操作）
  
  • 原理：用CAS指令实现无锁原子操作，乐观锁思想。
  • 特点：性能好。

MySQL层面的锁

• 全局锁：对整个数据库加锁
• 表级锁：锁定整个表，开销小，加锁快，并发度低，容易锁冲突。
  
  • 读锁：阻止写。
  • 写锁：阻止所有读写操作。
  • 元数据锁：操作元数据时自动添加，保护元数据一致性。
• 行级锁（InnoDB）：锁定单行或多行记录，开销大，加锁慢，并发度高，容易死锁。
  
  • 共享锁：
  • 排他锁：
  • 记录锁：锁定单个索引记录。
  • 间隙锁：锁定索引记录间的间隙。
  • 临键锁：记录锁 + 间隙锁
• 意向锁：表级锁，快速判断是否有行级锁的存在。

ReentrantLock 和 Synchronized 的区别？Synchronized 原理？

• Synchronized 是依赖于 JVM 实现的，而 ReetrantLock 是 API 实现的；
• 在 Synchronized 优化以前，synchronized 的性能是比 ReentrantLock 差很多的，但是自从 Synchronized 引入了偏向锁，轻量级锁（自旋锁）后，两者性能就差不多了；
• Synchronized 由编译器去保证锁的加锁和释放；ReentrantLock 需要手工加锁和释放锁
• ReentrantLock 可以指定是公平锁还是非公平锁，而 Synchronized 只能是非公平锁
• ReentrantLock 可响应中断、可重入，而 Synchronized 是不可以响应中断的

ReentrantLock 的实现原理？

ReentrantLock 基于 AbstractQueuedSynchronizer实现了几个方法：

• 公平锁：竞争锁的时按顺序排队，先到的先拿到锁。
• 非公平锁：竞争锁的时无视排队顺序，直接抢锁。两次尝试CAS获取锁，失败后才排队。

synchronized 锁升级过程，锁的升级、降级？

synchronized代码块是由 monitorenter 和 monitorexit 指令实现的。Java 6之前 Monitor 的实现依靠操作系统内部的互斥锁，因为需要进行用户态和内核态的切换，所以同步操作是个重量级操作。现代JDK中，JVM提供了偏向锁、轻量级锁、重量级锁三种Monitor实现，大大改进了其性能。

锁升级、降级就是JVM优化 synchronized 运行的机制，当JVM检测到不同的竞争状态时，会自动切换到适合的锁实现，这种切换就是锁的升级降级。

Java 对象结构分为 对象头、对象体、对齐字节。对象头包含三部分：

• Mark Word：存储自身运行数据（当前对象线程锁状态及 GC 标志）
• class 指针：指向方法区中该 class 的对象，JVM 通过此字段判断当前对象事哪个类的实例
• 数组长度：只有是数组时才会用到

锁升级过程按照无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁方向升级。当JVM进入安全点的时候，会检查是否有闲置的Monitor，然后试图进行降级。

1. 线程A在进入同步代码块前，先检查 MarkWord 中的线程 ID 是否与当前线程 ID 一致，如果一致，则直接无需通过 CAS 来加锁、解锁
2. 如果不一致，再检查是否为偏向锁，如果不是，自适应自旋等待锁释放
3. 如果是，在检查对应线程是否存在，如果不在，则设置线程 ID 为线程 A 的 ID，还是偏向锁
4. 如果在，撤销偏向锁，升级为轻量级锁。线程 A 自旋等待锁释放
5. 如果自旋到了阈值，锁还没释放，又有一个线程来竞争锁，此时升级为重量级锁。其他竞争线程都被阻塞，防止CPU空转
6. 锁被释放，唤醒所有阻塞线程，重新竞争锁

聊聊 AQS（抽象队列同步器）?

AQS是Java并发用来构建锁和其他同步组件的基础框架。AQS使用一个线程可见的state表示同步状态，通过内置的FIFO队列来完成线程的排队和调度，通过CAS对State值修改。

state变量 volatile int类型，表示同步状态

• 独占锁：初始state状态为0，线程获取锁state+1。
• 共享锁：state代表允许多少个线程获取锁。

AQS的核心思想是，如果被请求的共享资源空闲，就将当前请求线程设置为有效的工作线程，将共享资源设定为锁定状态；如果共享资源被占用，将暂时获取不到锁的线程加入队列中。

等待队列：CHL双向链表，FIFO，未争抢到锁的线程会被放入等待队列

条件队列：

1. 当前线程 threadA 调用 wait/await方法，表示当前线程要暂时释放锁，则当前线程进入条件队列的队尾；
2. 同步队列或者其他线程 threadB 获取到锁；
3. threadB 线程调用singal方法，将条件队列队首的线程移到同步队列，并调用acquireQueued方法尝试争抢锁，通过判断前驱节点是不是头节点。

Disruptor

Disruptor是一个高性能异步处理框架，能够在无锁的情况下实现队列的并发。
使用环形数组实现了类似队列的功能，并且是一个有界队列。通常用于生产者-消费者场景

核心设计原理

• 环形数组结构
  
  • 为了避免垃圾回收，使用数组代替链表
  • 数组对CPU的缓存机制更友好，遍历更快
• 元素位置定位
  
  • 数组长度2^n，可以通过位运算提升定位的速度
  • 数组中元素下标采用递增的形式
  • index采用long类型，不用担心index溢出的问题
• 无锁设计：生产者/消费者线程会先申请可以操作的元素在数组中的位置，申请到之后直接在该位置写入/读取数据，整个过程中通过原子变量CAS，保证操作的线程安全

优点

• 使用无所队列实现并发操作，性能高
• 所有访问者都记录自身序号的实现方式，允许多个生产者和多个消费者共享相同的数据结构
• 在每个对象(包括RingBuffer,WaitStrategy)，生产者和消费者中都能跟踪序列号，使用了缓存行填充cache line padding，这样就没有伪共享和非预期的竞争

详细参考：高性能并发队列Disruptor使用详解

框架

Spring

@Autowired的实现原理

@Autowired注解用于自动装配Bean，实现主要依赖于Spring容器中的一个后置处理器：AutowiredAnnotationBeanPostProcessor。

1. Spring容器启动时，会实例化并注册各种后置处理器，包括AutowiredAnnotationBeanPostProcessor。
2. 当Spring容器创建Bean实例时，在doCreateBean()方法中会调用populateBean()方法，来为bean进行属性填充，完成自动装配等工作。
3. AutowiredAnnotationBeanPostProcessor会在这些方法中，扫描Bean的属性、方法参数等，查找标注了@Autowired注解的地方。
4. 找到@Autowired注解后，会根据类型匹配、名称匹配等规则，从Spring容器中查找对应的Bean。
5. 找到匹配的Bean后，会通过反射机制将找到的Bean注入到当前Bean的属性或方法参数中。

Bean的默认作用范围是什么？其他的作用范围？

Bean的生命周期

1. 定义：启动时扫描XML、注解或配置类中需要被Spring管理的Bean信息，装到BeanDefinitionMap中，真实对象还未实例化；
2. 实例化：Spring 使用反射机制为Bean分配内存空间，但此时Bean对象的属性还未注入；
3. 属性填充：将当前类依赖的Bean属性进行注入和装配。
4. 初始化：
   
   1. 执行各种通知；BeanNameAware、BeanFactoryAware、ApplicationContextAware接口；
   2. 执行初始化的前置方法；BeanPostProcessor的postProcessBeforeInitialization方法；
   3. 执行初始化方法；@PostConstruct或者会调用InitializingBean接口的afterPropertiesSet()方法；
   4. 执行初始化的后置方法。BeanPostProcessor的postProcessAfterInitialization方法。
5. 使用
6. 销毁：DisposableBean接口的destroy()方法或者@PreDestroy注解的方法。

SpringBoot

如何定义一个starter

1. 新建两个模块，命名规范：xxx-spring-boot-starter
   
   • xxx-spring-boot-autoconfigure：自定配置核心代码
   • xxx-spring-boot-starter：管理依赖
2. 在 xxx-spring-boot-autoconfigure 项目中
   
   1. 引入 maven 依赖
   2. 创建自定义的 XXXProperties 类：类中的属性要出现在配置文件中
   3. 创建自定义类，实现自定义功能
   4. 创建自定义的 XXXAutoConfigure 类：用于自动配置时的一些逻辑，需将上方自定义类进行 Bean 对象创建，同时让 XXXProperties 类生效
   5. 创建自定义的spring.factories文件：在resource/META-INF创建一个 spring.factories文件和spring-configuration-metadata.json，分别用于导入自动配置类(必须有)、用于在填写配置文件时的智能提示(可以没有)。
3. 在 xxx-spring-boot-starter 项目中引入 xxx-spring-boot-autoconfigure 依赖，其他项目使用时只需依赖 xxx-spring-boot-starter 即可

JVM

类加载机制？双亲委派模型？

类加载过程：获取类的二进制字节流 -> 结构化静态存储结构 -> 在内存中生成 Class 对象
双亲委派模型：类加载请求先交给父类加载器，加载不了子类加载器才会尝试加载。避免重复加载，保证安全性。

• 启动类加载器：加载 java 核心类库 \lib、-Xbootclasspath指定路径
• 扩展类加载器：加载扩展库 \lib\ext
• 应用类加载器：加载 classpath 路径下的类
• 自定义类加载器

Java内存模型(JMM)？

JMM 是用于描述 Java 程序中多线程并发访问共享内存的规范。

共享变量与可见性

为了确保每个线程都能看到其他线程对共享变量的修改，Java 内存模型提供了一系列规则。例如：

• 当一个线程修改了一个 volatile 变量的值后，其他线程能立即看到这个修改。
• 在进入和退出 synchronized 块时，线程对共享变量的操作对其他线程是可见的。

有序性

为了避免指令重排导致多线程程序出现意想不到的结果，Java 内存模型定义了 happens-before 规则来确保多线程间的操作顺序符合预期。

原子性

Java 内存模型还规定了某些操作具有原子性。例如：对 volatile 变量的读写操作。对于非原子性的操作，需要使用锁等机制来保证线程安全。

主内存和工作内存

• 主内存线程共享。
• 工作内存线程私有，存储主内存中共享变量的副本。
• 线程对变量的操作在工作内存中进行，操作完成后再将变量写回主内存。

JVM内存结构？

各部分内存的合理配置和优化对JVM性能至关重要。

• 堆：存放对象实例和数组，共享；
• 方法区：存放类型信息、常量池、静态变量、JIT编译后的代码。共享。
• 栈：栈中有栈帧，私有。主要存放
  
  • 局部变量表：存放方法参数、局部变量。
  • 操作数栈：存放方法执行过程的中间结果、操作数。
  • 动态链接：存放指向运行时常量池的方法引用。
  • 方法出口：存放方法执行完成后的返回地址。
• 本地方法栈：执行本地方法，私有；
• 程序计数器：存放当前线程执行的字节码的行号，私有。

JVM加载类的阶段、static成员变量在各个阶段中发生了什么变化

源码到代码执行过程：编译 -> 加载 -> 解释 -> 执行
编译阶段：语法分析 -> 语义分析 -> 注解处理 -> class文件

加载阶段：装载 -> 连接 -> 初始化

装载阶段：查找并加载类的二进制数据，在 JVM 堆中创建一个 java.lang.Class类的对象，并将类相关的信息存储在 JVM 方法区中。
连接阶段：对 class 的信息进行验证、为类变量分配内存空间并对其赋默认值

1. 验证：验证类是否符合 java 规范和 JVM 规范
2. 准备：为类的静态变量分配内存，初始化为系统默认值
3. 解析：将符号引用转为直接引用
   初始化：为类的静态变量赋予正确的初始值

解释阶段：把字节码转换为操作系统识别的指令
JVM 会检测热点代码，超过阈值会触发即时编译，生成机器码保存起来，下次直接执行

执行阶段：调用操作系统执行指令

在JVM内存模型下，说说一个对象初始化的整个过程

1. 类加载检查：首先检查要创建的对象的类是否已经被加载。如果未加载，会触发该类的加载、验证、准备、解析、初始化过程，将类的元数据（如静态变量、方法信息）加载到方法区。在准备阶段，静态变量会被赋零值；在初始化阶段，会执行静态代码块和静态变量的赋值。

2. 内存分配：确认类已加载后，会在堆上分配内存空间。

3. 赋零值：对象实例变量部分赋上默认的零值。

4. 设置对象头：新对象的内存空间会设置对象头，包含对象哈希码、GC 信息以及指向其类元数据（方法区）的指针。

5. 执行构造器：执行代码层面的构造器方法，方法的局部变量和操作数存储在虚拟机栈。

6. 赋值引用：将对象引用赋值给成员变量，局部变量-虚拟机栈、实例变量-堆、静态变量-方法区。

Java堆的分区，比例，如果调大比例后会有什么样的后果？

默认的，Young:Old=1:2 (可通过参数 –XX:NewRatio 来指定)。其中，新生代(Young)被细分为 Eden 和 两个 Survivor 区域，这两个 Survivor 区域分别被命名为 from 和 to。老年代过小会导致频繁发生 fullGC，继而导致 STW
默认的，Eden:from:to = 8:1:1 (可通过参数 –XX:SurvivorRatio 来设定)，新生代比例过小会导致频繁发生MinorGC

Java怎么进行垃圾回收的？

Java 的 GC 机制负责识别并回收不再被程序使用的对象，从而避免内存泄漏和溢出问题。垃圾回收过程：

1. 标记：标记存活对象；
2. 清除：回收未标记的对象的内存空间；
3. 整理（可选）：酱存货对象移动到一起，减少内存碎片。

什么时候对象进入老年代？

• 大对象直接进入老年代
• 长期存活的对象
• 动态对象年龄判定：Survivor 区中所有相同年龄的对象的大小总和大于 Survivor 空间的一半，则年龄大于或等于该年龄的对象就直接进入老年代
• 空间分配担保：担保的前提是自己本身还有容纳这些对象的剩余空间，由于无法提前知道会有多少对象存活下来，所以取之前每次晋升到老年代的对象的平均大小作为经验值，与老年代的剩余连续空间做比较

JVM的GC算法，为什么“标记-整理”更好一些，能解决什么问题？

标记-整理：标记出所有存活对象，将所有存活对象向内存一边移动，清理掉边界以外的部分。

解决内存碎片问题。主要用于老年代，移动存活对象代价比较大，而且需要STW，从整体的吞吐量来考量，老年代使用标记-整理算法更合适。

什么情况会触发 FullGC?

• 调用System.gc()时，会告诉 JVM 可以GC
• 创建大对象新生代放不下，老年代也放不下，会触发 FullGC
• Survivor 空间不够用，会通过分配担保机制，将多出来的对象提前转到老年代，如果老年代的可用内存小于该对象的大小，就会触发 Full GC
• 当老年代中最大可用的连续空间<历代晋升到老年代的对象的平均大小时，会触发Full GC 来让老年代腾出更多空间

看线上正在运行的服务的GC日志，你需要输入什么指令?

jmap -histo:live PID | head -n20：查看对应进程对象中占用空间较大的前20个对象
jstat -gcutil -h20 PID 1000：查看堆内存各区域使用率及 GC 情况
jstat -gc PID 1000：查看 GC 次数时间等，一秒一次
jmap -dump:live,format=b,file=heap4.hprof PID：使用 jmap 生成 dump 文件后再详细分析

G1和CMS垃圾回收器的区别，哪几个过程中会STW? G1的region

1. 使用范围不一样
   CMS：老年代，需要配合新生代Serial/ParNew一起使用
   G1：新生代、老年代
2. STW 的时间
   CMS：以最小停顿时间为目标
   G1：可预测垃圾回收的停顿时间
3. 垃圾碎片
   CMS：使用“标记清除”算法，容易产生内存碎片
   G1：“标记整理”算法，没有内存碎片
4. 垃圾回收过程不一样
   CMS：初始标记(STW)、并发标记、重新标记(STW)、并发清除
   G1：初始标记(STW)、并发标记、最终标记(STW)、筛选回收(STW)
5. CMS会产生浮动垃圾

G1将Java堆划分为2048个大小相同的独立 Region 块，每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理

GC策略及选择

GC策略

Serial：单线程，垃圾收集时必须暂停其他所有工作线程直到收集结束。

• 特点：CPU 利用率最高，停顿时间较长。
• 适用场景：堆大小在100MB以内、一个单核单线程对暂停时间无要求。通过-XX:+UseSerialGC指定。

Parallel：多线程，并行标记扫描

• 特点：停顿时间短，回收效率高，对吞吐量要求高。
• 适用场景：高峰期较好性能，对停顿时间无高要求。-XX:UseParNewGC：新生代并行回收；-XX:+UseParallelOldGC：新生代和老年代都使用并行收集器。

CMS：多线程，采用“标记-清除”算法实现。初始标记、并发标记、并发预处理、重新标记、并发清除、并发重置。

• 特点：响应时间优先，减少停顿时间。
• 适用场景：对停顿延迟有高要求。-XX:+UseConcMarkSweepGC开启。

G1：堆被划分为许多连续的区域，采用G1算法回收。

• 特点：支持很大的堆，高吞吐量支持多CPU和垃圾回收线程。主线程暂停情况下使用并行收集，主线程运行的情况下使用并发收集。
• 适用场景：可预测的停顿，堆很大。-XX:UseG1GC开启。

JVM 调优

什么时候考虑 JVM 调优？

• 堆内存（老年代）持续上涨达到设置的最大内存值；
• Full GC 次数频繁；
• GC 停顿事件过长（超过1秒）；
• 应用出现 OutOfMemory 等内存异常；
• 应用中有使用本地缓存且占大量内存空间；
• 系统吞吐量与响应性能不高/下降；

JVM 调优的目标

• 延迟：GC 低停顿和 GC 低频率
• 低内存占用
• 高吞吐量

JVM 调优量化目标

• 堆内存使用率 <= 70%
• 老年代内存使用率 <= 70%
• 平均暂停时间 <= 1秒
• full gc 次数0 或者平均暂停间隔 >= 24小时

JVM 调优的步骤

1. 分析 GC 日志及 dump 文件，判断是否需要优化，确定瓶颈问题点；
2. 确定 JVM 调优量化目标；
3. 确定 JVM 调优参数（根据历史 JVM 参数来调整）；
4. 依次调优内存、延迟、吞吐量等指标；
5. 对比观察调优前后的差异；
6. 不断分析和调整，直到找到合适的 JVM 参数配置；
7. 找到最合适的参数，将这些参数应用到所有服务器，并进行后续跟踪。

常见的 JVM 参数

堆栈配置相关

• -Xmx：最大堆大小
• -Xms：初始堆大小
• -Xmn2g：设置年轻代大小为 2g；
• -Xss128k：每个线程的堆栈大小为 128k；
• -XX:MaxPermSize=16m：设置持久代大小为 16m；
• -XX:NewRatio=4：设置年轻代（Eden + 两个 Survivor 区）与老年代的比值（除去持久代）；
• -XX:SurvivorRatio=4：设置年轻代中 Eden 区与 Survivor 区的大小比值。 Eden:S0:S1=4:1:1，一个 Survivor 区占整个年轻代的 1/6；
• -XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为 0 的话，则年轻代对象不经过 Survivor 区，直接进入年老代。

垃圾收集器相关

• -XX:+UseParallelGC：选择垃圾收集器为并行收集器；
• -XX:ParallelGCThreads=20：配置并行收集器的线程数；
• -XX:+UseConcMarkSweepGC：设置年老代为并发收集；
• -XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片；
• -XX:+UseConcMarkSweepGC 使用 CMS 垃圾收集器。

辅助信息

• -XX:PrintGC
• -XX:+PrintGCDetails

常用调优策略

• 选择合适的垃圾收集器；
• 调整内存大小（垃圾收集频率非常频繁）
• 调整内存区域大小比率（某一个区域的 GC 频繁，其他都正常）
• 调整对象升老年代的年龄（老年代频繁 GC，每次回收的对象很多）
• 调整大对象的标准（老年代频繁 GC，每次回收的对象很多，而且单个对象的体积都比较大）
• 调整 GC 的触发时机（CMS、G1 经常 Full GC，程序卡顿严重)
• 调整 JVM 本地内存大小（GC 的次数、事件和回收的对象都正常，堆内存空间充足，但是报 OOM）

MySQL

SQL查询语句是如何执行的？

一条查询语句的执行过程一般是经过连接器、分析器、优化器、执行器等功能模块，最后到达存储引擎

执行语句前要先连接数据库，分析器会通过词法和语法解析知道这是一条更新语句，会把表T上所有缓存结果都清空。优化器决定要使用哪这个索引，然后执行器负责具体执行，找到这一行，然后更新。

MySQL锁

在 InnoDB 引擎下，按照锁的粒度，可以简单分为行锁和表锁。

行锁是作用在索引上的，SQL命中了索引，锁住的就是命中条件内的索引节点（行锁）。如果没有命中索引，那锁住的就是整个索引树（表锁）。

行锁可以简单分为读锁和写锁。读锁是共享的，多个事务可以读取同一个资源，但不允许其他事务修改。写锁是排他的，写锁会阻塞其他的写锁和读锁。

事务的四大特性

• 原子性：由 undo log 保证（回滚日志，用于记录数据被修改前的信息）
• 持久性：由 redo log 保证（重做日志，记录的是事务执行过程中数据页的修改情况）
• 隔离性：由数据库隔离级别提供
• 一致性：是事务的目的，由应用程序保证

MySQL隔离级别，分别解决什么问题

• 读未提交：读不加锁，会有脏读、重复度、幻读的问题
• 读已提交：MVCC（多版本并发控制）提高读写性能，避免脏读。MVCC通过生成数据快照，思想是每一次查询都会产生一个新的Read View副本，等到其他事务提交后，才会读取最新的已提交的版本号数据。通过“版本”概念解决脏读问题，会有重复读和幻读的问题
• 可重复度：默认，每次读取的都是当前事务的版本。会有幻读的问题
• 串行化：事务之间是串行的，效率最低，安全性最高

MVCC原理

1. 获取事务自己的版本号，即事务ID
2. 获取 Read View
3. 查询到的数据，然后与 Read View 中的事务版本号进行比较
4. 如果不符合 Read View 的可见性规则，就需要 undo log 中历史快照
5. 最后返回符合规则的数据

索引

B+ 树和 B树的主要区别？B+ 树索引，一次查找过程?

B+ 树是有序的，和B-树的主要区别：

• B-树内部节点是保存数据的；而 B+ 树内部节点不保存数据，只做索引用，叶子节点才保存数据
• B+树相邻的叶子节点之间是通过链表指针连起来的，B-树不是

假设由如下SQL：age 加个索引，这条 SQL 是如何在索引生执行的？

select * from Temployee where age=32;

这条 SQL 查询语句的执行大概流程：

• 搜索 idx_age 索引树，将磁盘块 1 加载到内存中，由于 32<37 搜索左路分支，到磁盘寻址磁盘块 2；
• 将磁盘块 2 加载到内存中，在内存中继续遍历找到 age=32 的记录，取得 id=400;
• 搜索 id 主键索引树，将磁盘块 1 加载内存，在内存中遍历找到 400。但是 B+树索引非叶子节点是不保存数据的。索引会继续搜索 400 的右分支，到磁盘寻址磁盘块 3；
• 将磁盘块 3 加载内存，在内存遍历，找到 id=400 的记录，拿到 R4 这一行的数据

MongoDB为啥用B树而不是B+树

• B-树所有节点都存储数据，因此在查询单条数据的时候，B树的查询效率不固定，最好的情况是O(1)。我们可以认为在做单一数据查询的时候，B树的平均性能更好，但不适合做一些数据遍历操作。
• B+树的数据只出现在叶子节点上，因此查询单条数据的时候，查询速度非常稳定，但是在单一数据查询上平均性能不如B树。因为叶子节点有指针相连，适合做范围查询
• MonogoDB是nosql，对遍历的需求没有关系型数据库强烈

InnoDB 存储引擎中的行锁的加锁规则

InnoDB 三种行锁:
- Record Lock(记录锁)：锁住某一行记录
- Gap Lock(间隙锁)：锁住一段左开右开的区间(m, n)
- Next-key Lock(临键锁)：锁住一段左开右闭的区间(m, n]

1. 对于 update、delete、insert，InnoDB 会自动给相应记录行加写锁
2. 对普通 select 语句不加锁，但是在 Serializable 隔离级别下会加行级读锁
3. select …… for update加行级写锁
4. select …… lock in share mode加行级读锁

查找过程中访问到的对象才会加锁
加锁的基本单位是临键锁

慢sql优化如何做？

发现慢SQL

• 慢查询日志：修改MySQL配置文件(my.cnf 或 my.ini)，设置slow_query_log=1和long_query_time=N(N为慢查询阈值，单位为秒)。慢查询日志位置由slow_query_log_file参数指定。
• 性能监控工具：第三方工具

分析慢SQL

• EXPLAIN命令：看是否使用索引、扫描行数等。
  
  • type：访问类型，ALL全表扫描、index索引扫描、range范围扫描、ref使用索引查找等
  • key：实际使用的索引。
  • rows：估计需要扫描的行数。
  • Extra：额外信息，如Using filesort文件排序、
• Profiling：详细了解SQL执行过程和每个阶段耗时。

优化慢SQL

• 索引优化：合适列创建索引、选择合适的索引类型、多条件查询创建联合索引
  
  • 最左前缀原则
  • 避免再索引列使用函数或表达式
  • 索引数量不能太多
• SQL语句优化
  
  • 避免SELETE *
  • 用JOIN代替子查询
  • 优化WHERE子句
  • 减少排序和分组
  • 使用LIMIT限制结果集大小
• 数据库结构优化
  
  • 分表分库
  • 读写分离
  • 缓存：缓存热点数据，减少数据库访问压力

其他优化方法

• 硬件优化
• 参数优化：innodb_buffer_pool_size控制缓冲池大小，适当增加；query_cache_size控制查询缓存大小
• 应用层优化
  
  • SQL语句优化：避免不必要的查询
  • 连接池：使用连接池管理数据库连接
  • 事务：合理使用事务，减少锁竞争

数据库优化

• 打破范式设计；冗余少量字段方便查询，需要源表和冗余表保证同一事物写。
• 关联关系在业务层面约束，不依赖数据库外键
• 字段拓展性；结构不清晰的字段使用json类型，json检索少量key可以使用虚拟列并建立索引，多条件检索直接es
• 冷热分离；源表拆分成多张表，可以把频繁变更的字段放在主表，使用率较低的放在副表，判断依据可以是创建时间、业务域
• 服务拆分在分片字段选择上尽量考虑使用本地事务，让同业务的不同sql命中同一个分表，以避免使用分布式事务
• 尽量使用单表维度sql，原因：join性能差；后期分库分表更方便，前瞻性设计要考虑使用哪种ID主键策略

分库分表

缺点
- 事务问题，不能用本地事务，需要分布式事务；
- 跨节点 Join 的问题：解决这一问题可任意分两次查询实现；
- 跨节点的 count、order by、group by 以及聚合函数问题：分别在各个节点上得到结果后在应用程序端进行合并；
- ID 问题：数据库被切分后，不能再依赖数据库自身的主键生成机制，最简单可以考虑 UUID；
- 跨分片的排序分页问题（后台加大 pagesize 处理）

1. 为什么要分库、分表
   分库：拓展磁盘存储、并发连接支撑
   分表：单表大量数据时，存储和查询性能会遇到瓶颈，考虑分表分摊压力
2. 什么时候考虑
   
   • 阿里《Java开发手册》中推荐
     

     单表行数超过500万行或者单表容量超过2GB，才推荐进行分库分表。

   • 根据业务提前预估
3. 以什么维度来分表
   先找到业务的主题，比如表是一张客户信息表，可以考虑以客户id来分表
4. 非分表键如何查询
   
   • 遍历：简单粗暴（不建议）
   • 将用户信息冗余同步到ES，通过ES来查询（推荐）
5. 分表策略
   
   • 范围划分，比如以订单id，以订单作为分表键，300w一个表；或者时间，通常用于冷热数据分离
     优点：扩容方便
     缺点：会有热点问题
   • Hash取模，以指定的路由key(比如用户id、订单id)取哈希后对分表数取模，将数据分散到各个表中
     优点：不会存在明显的热点问题
     缺点：扩容比较麻烦，需提前规划好

6. 跨节点join关联问题
   解决思路：字段冗余、全局表(基础表每个库中保存一份)、数据同步、应用层代码组装

7. 聚合函数问题：分别在各个节点上得到结果后，在中间件/应用端合并

8. 分库分表后的分页问题
   
   • 全局视野法：在各数据库查到对应结果后再代码端汇聚再分页。缺点是会返回过多数据
   • 业务折衷：禁止跳页查询，需要业务妥协
9. 分布式ID：考虑使用雪花算法生成
10. 分库分表中间件：推荐使用 Apache ShardingSphere
11. 分表要停服吗？不停服如何做？
    
    • 编写代理层，加个开关，灰度期间还是访问老的DAO
    • 发版全量后，开启双写，既在旧表新增和修改，也在新表新增能够和修改。日志/临时表记下新表ID起始值，旧表中小于这个值的数据就是存量数据，这批数据就是要迁移的
    • 通过脚本把旧表的存量数据写入新表
    • 停读旧表改读新表，此时新表已经城在了所有读写业务，但是这时候不要立即停写旧表，保持双写一段时间
    • 当读写新表一段时间后，如果没有业务问题，就可以停写旧表了

双机热备

• Mysql+Keepalived实现双主热备
• Centos 7 安装系列(6)：MySQL + KeepAlived 双主热备

网络/IO

TCP

四次挥手过程，为什么是四次？

四次挥手中有TIME_WAIT和CLOSE_WAIT状态，是出现在哪一方的？

假设 TIME_WAIT 状态过多会有什么危害，怎么解决？

为什么TCP4次挥手时等待为2MSL？

怎么实现拥塞控制？

• 慢启动
• 拥塞避免
• 拥塞发生
• 快速恢复

• 每收到一个 ACK 时，cwnd = cwnd + 1/cwnd
• 当每过一个 RTT 时，cwnd = cwnd + 1

• RTO 超时重传
• 快速重传

• 拥塞窗口大小 cwnd = cwnd/2
• 慢启动阈值 ssthresh = cwnd
• 进入快速恢复算法

• cwnd = sshthresh + 3
• 重传丢失的那几个 ACK 数据包
• 如果在收到重复的 ACK，那个 cwnd = cwnd + 1
• 如果收到新数据的 ACK 后，cwnd = sshthresh。收到新数据的 ACK 表名恢复过程已经结束，可以再次进入拥塞避免的算法了

如何保证数据可靠性和顺序性

负载均衡

• 二层负载均衡(数据链路层mac)：虚拟mac地址，外部对虚拟mac地址请求，负载均衡后分配给对应的mac地址响应
• 三层负载均衡(网络层ip):虚拟IP地址的方式，外部对虚拟的IP地址请求，负载均衡后分配给实际的mac地址响应
• 四层负载均衡(传输层tcp):在三层负载均衡的基础上，用ip+port接收请求，再转发到对应的机器
• 七层负载均衡(应用层http):根据虚拟的ip+port、主机名接受请求，在转给响应的处理服务器

IO

IO 模型

• 阻塞I/O：应用进程被阻塞，直到数据复制到应用进程中缓冲区中才返回
• 非阻塞I/O：应用进程执行系统调用后，内核返回一个错误码。应用进程可以继续执行，但需要不断轮询来获知 I/O 是否完成
• I/O 多路复用：一个线程可以监视多个文件描述符，此过程会被阻塞。一旦某个就绪，通知应用程序读写
• 信号驱动式 I/O：向内核发送一个信号SIGIO，然后应用程序立即返回。当内核数据准备号后，再通过SIGIO信号通知应用进程。应用进程收到信号后使用recvfrom去读取数据（数据复制到应用缓冲区期间，进程阻塞）
• 异步 I/O：应用进程发出系统调用后立即返回，等内核准备好数据，将数据拷贝到应用进程缓冲区，发送信号通知应用进程IO操作完毕

Java中的BIO、NIO、AIO的区别和联系

• BIO：阻塞IO，线程发起I/O操作后，必须等待操作完成才能进行其他任务。适合连接数少且固定的场景。
• NIO：非阻塞IO，线程在等待I/O操作完成时可以做其他任务。适合连接数多，但并发读写相对较少的场景。
• AIO：异步IO，无需等待I/O操作的完成，操作完成时操作系统会通知应用程序。适合连接数多，且并发读写操作也多的场景。

NIO 和多路复用的区别？

• select：监听的 I/O 最大连接数有限，Linux 一般是 1024，可以调大；需要遍历 fdset，找到就绪的 fd

• poll：poll解决了连接数的限制

• epoll：采用事件驱动，epoll 先通过 epoll_ctl() 来注册一个 fd（文件描述符）。一旦某个 fd 就绪时，内核会采用回调机制，迅速激活这个 fd，当进程掉 epoll_wait() 时便得到通知，采用监听事件回调机制。

  

零拷贝

• 传统的I/Oread+write方式会产生2次DMA拷贝+2次CPU拷贝，同时有4次上下文切换。
• mmap+write方式则产生2次DMA拷贝+1次CPU拷贝，4次上下文切换，通过内存映射减少了一次CPU拷贝，可以减少内存使用，适合大文件的传输。
• sendfile方式是新增的一个系统调用函数，产生2次DMA拷贝+1次CPU拷贝，但是只有2次上下文切换。因为只有一次调用，减少了上下文的切换，但是用户空间对IO数据不可见，适用于静态文件服务器。
• sendfile+DMA gather方式产生2次DMA拷贝，没有CPU拷贝，而且也只有2次上下文切换。虽然极大地提升了性能，但是需要依赖新的硬件设备支持。

缓存

缓存雪崩、缓存穿透、缓存击穿，如何应对？

雪崩：缓存机器宕机，导致请求全部打到数据库上，打死数据库

穿透：大量构造的恶意请求，导致缓存查不到，最终打死数据库

击穿：热点key再失效的瞬间，大量请求直接请求到数据库，打死数据库

布隆过滤器：通过一个bit数组和多个哈希函数判断某个元素是否存在于一个集合中。
核心思想是使用哈希函数将元素映射到为数组的不同位置，并在这些位置1。查询时通过哈希函数判断某个元素对应的位是否全为1，如果是，可能存在该元素；如果有0，则一定不存在。

哈希函数存在碰撞，所以可能会误判元素存在。

redis 内存满了会发生什么？

1. 如果 redis 配置了内存淘汰策略，则会通过定时删除、惰性删除、定期删除等方式淘汰过期的key，如果配置的淘汰策略淘汰不掉，则报错OOM
2. 如果启用了虚拟内存机制，会将部分最老数据的value持久化到磁盘

Redis如何解决key冲突？

通过链地址法、重新哈希、渐进式哈希、负载因子、哈希桶等多种机制来解决键冲突的问题。

链地址法：多个键被哈希到同一个位置时，使用链表将键值对连起来。

• 优点：处理冲突效率高；缺点：链表过长时影响效率。

重新哈希：当哈希表中键值对数量达到一定阈值时，会自动扩容重新哈希。

• 优点：有效减少哈希冲突；缺点：扩容过程需要消耗一定资源。

渐进式哈希：将重新哈希的过程分摊到多个操作中，每次只迁移一部分键值对。

• 优点：减少扩容过程对性能的影响。

负载因子：会根据负载因子大小决定是否扩容，保证哈希表性能。

哈希桶：发生哈希冲突时，会将冲突的键值对存储在同一个哈希桶中。减少哈希冲突，提高性能。

Redis 发布订阅(pub/sub)

类似于 RocketMQ中广播模式，简单易上手

优点：轻量级、低延迟、低可靠性
缺点：

• redis 发布/订阅模型消息无法持久化，消费者消费过慢会撑爆内存；一经发布，没有任何订阅方处理，该条消息就会丢失
• 没有类似ACK的机制
• 广播机制，下游消费能力取决于消费方本身

使用需考虑：消费者并发数、生产的速度和消费的速度、是否需保证可靠性

如果要求可靠性 & redis版本>=5.0，可以考虑使用 Redis Stream，如果有更复杂的要求，还是考虑使用专门的消息队列（kafka、RocketMQ、Pulsar等）

什么是一致性Hash算法

一致性 Hash 算法能够在 Hash 输出空间发生变化时，引起最小的改动。应用在像分布式系统扩容缩容的时候。

原理是将整个哈希输出空间设置为一个环形区域，对数据进行 Hash 操作，映射在环形区域上，然后让该值沿顺时针方向移动，遇到的第一个服务器就是它分配的节点。

当服务节点很少的时候，会有很多 key 被分配到同一个服务实例上，称之为“数据倾斜”。如何解决？虚拟节点，即对内阁服务节点计算多个哈希，每个计算结果位置都放置一个此服务节点，称之为虚拟节点。具体做法可以在服务器 ip 或主机名的后面增加编号来实现。同时数据定位算法不变，只是多了一步虚拟节点到实际节点的映射。虚拟节点越多数据月均匀，一般虚拟节点数要在32个以上

如何保证数据库与redis缓存一致

没有一个完美方案可以适用于所有场景。

旁路缓存：先更新数据库，再删缓存。

• 优点：实现简单，可以保证最终一致性。
• 缺点：如果删除缓存失败，会导致数据不一致。存在数据不一致的可能。
• 适用场景：对数据一致性要求不高、容忍短暂不一致的场景。

延迟双删：先更新数据库，再删缓存，延迟一段时间后再删一次。

• 优点：减少数据不一致的概率。
• 缺点：延迟时间需要根据业务调整。
• 适用场景：对数据一致性要求较高的场景。删除的动作有多种选择：
  
  • 使用DelayQueue，会随着JVM进程死亡丢失更新的风险。
  • 放在MQ，编码复杂度增加。

读写请求串行化

• 优点：解决数据库缓存不一致的问题。
• 缺点：吞吐量大幅降低，一般不选。

ELK

搞懂ELK并不是一件特别难的事

消息队列

RocketMQ

如何保证高可用

• 发送高可用
  
  • 重试机制：只支持同步发送，默认3次。
  • 故障规避机制：开启故障规避机制，发送失败后会将失败的Broker暂时排除在外，过段时间会再试，如果一直不可用就会被剔除。
• 存储高可用
  
  • 消息持久化：同步刷盘、异步刷盘
  • 主从复制：主节点挂了，还可以从从节点拉取消息。分为同步复制、异步复制。
  • 读写分离
• 消费高可用
  
  • 消费重试机制：重试队列、死信队列
  • ACK机制
• Broker集群部署

详见RocketMQ是如何保证高可用的？

如何保证消息不丢失

可能丢失的情况：

1. 生产者发消息时丢失。

   同步发送 + 重试机制 + 部署多个broker

   同步重试机制：如果同步模式发送失败，则轮转到下一个Broker。

2. broker存储消息时丢失。broker会将消息写入缓冲区，再发送给生产者回执，最后异步刷盘。如果刷盘过程中broker宕机了，会导致消息丢失。

   同步刷盘 + 同步复制 + 主从

   同步刷盘：消息真正持久化到磁盘后，Broker才会返回一个ACK，保证可靠性，但影响性能。
   异步刷盘：消息写入PageCache就返回ACK，后台异步刷盘，提高性能和吞吐量，可能丢消息。

   同步复制：消息投递到主从节点都落盘成功，Broker才会当作消息投递成功。增大延迟，降低吞吐。
   异步复制：只要master写入消息成功，就反馈给客户端写入成功的状态。速度快，同样可能丢消息。

   Broker重试机制：消息消费失败会写入重试Topic，最大重试16次，如果还不行会写入死信队列。

3. 消费者消费时候丢失。网络、消费者宕机。

   手动ACK + 消费重试机制 + 尽量不要异步消费

兜底方案：存到其他地方，用定时任务重新发送来降级处理。

如何保证消息消费不重复

• 消息消费确认机制
• 消费端幂等性设计

如何保证消费的幂等性？

• 比如要写库，现根据主键查一下，如果这数据有了，就 update 一下
• 如果是写 Redis，每次都是 set，天然幂等
• 如果不是上面两种场景，需要让生产者发送每条数据的时候，里面加一个全局唯一的 id，消费的时候根据这个 id 去 Redis 里查一下，如果没有消费过就处理，消费过了就放弃处理
• 基于数据库的唯一键来保证重复数据不会多次插入

如何保证消息顺序

• 全局有序：某个Topic下的所有消息都要保证顺序；只能用一个队列，单个生产者，影响性能
• 局部有序：保证每一组消息被顺序消费即可。

顺序消费的核心：生产者有序生产 + 消费者有序消费。

1. 生产者有序生产：同步发送 + 自定义队列选择器，Hash取模保证同一个订单在同一个队列。

   注意！Broker宕机或者增加，也会短暂的造成部分消息无序。

2. 消费者有序消费：有序消费模式MessageListenerOrderly，是通过加分布式锁和本地锁保证同时只有一条线程去消费一个队列上的数据。

   注意！使用锁降低了吞吐量，因为顺序，后面消息会被前面消息阻塞，消费失败自动重试无法跳过，必须设置最大消费次数，处理好可能的异常情况。

定时任务

如何避免被重复调度？

一次调度任务只有一个机器执行，不会因为是分布式部署而出现多台机器同时执行某个job。思路是使用分布式锁

基于数据库实现分布式锁

• 悲观锁，使用 select……for update
• 乐观锁，通过递增的版本号来实现

Quartz：acquireTriggersWithinLock=true获取 trigger 的时候上锁（抢占式获取数据库锁并由抢占成功的节点负责运行），默认是 false，使用乐观锁，但可能出现 ABA 导致重复调度

XXL-JOB：使用数据库悲观锁

• setAutoCommit(false)关闭隐式自动提交
• select lock for update显式排他锁，其他事务无法进入&无法实现for update
• 读数据库任务信息 -> 拉任务到内存时间轮 -> 更新数据库任务信息
• commit提交事务，同时释放for update排他锁（悲观锁）

基于缓存(redis)实现分布式锁

1. 获取锁的时候，使用 setnx 命令设置锁、设置过期时间，value 作为一个随机字符串，解锁时用来判断
2. 获取锁的时候，增加超时时间
3. 解锁时通过随机字符串判断是不是同一把锁

性能高，但redis master-slave架构的主从异步复制导致的redis分布式锁的最大缺陷：在redis master实例宕机的时候，可能导致多个客户端同时完成加锁。

基于 zookeeper 实现分布式锁

1. 创建目录 mylock
2. 线程 A 想获取锁，就在 mylock 目录下创建临时节点，会返回一个数字
3. 获取 mylock 目录下的所有节点，获取比自己小的兄弟节点，如果不存在说明当前线程的序号最小，那么他就获取了当前这把锁
4. 线程 B 创建一个临时顺序节点，判断自己是不是最小节点，设置监听比自己小一位的节点
5. 线程 A 处理完毕，删除自己的节点。线程 B 监听到了变更事件，判断自己是不是最小的，如果是则获取到锁

可靠性高，但性能不如redis分布式锁

分布式

单机演变为分布式，涉及哪些技术的调整？

单机系统演变为分布式系统是一个复杂的过程，需要根据具体的业务需求和场景，选择合适的技术方案，逐步完成系统的改造。

前端负载均衡

• 问题：单机难以承受高并发请求，需要将流量分发到多台服务器。

• 解决方案：引入负载均衡器

• 技术调整：负载均衡算法、健康检查、会话保持

服务拆分

• 问题：单机代码耦合度高，无法维护。

• 解决方案：将系统拆为多个独立服务，每个服务负责特定业务。

• 技术调整：微服务架构、服务注册与发现、API 网关。

数据库拆分

• 问题：单机数据库难以承受高并发读写请求，且存在单点故障风险。
• 解决方案：将数据库分片
• 技术调整：分库分表、分布式事务、读写分离

分布式缓存

• 问题：单机内存容量有限，无法满足高并发场景下的缓存需求。

• 解决方案：引入分布式缓存

• 技术调整：缓存集群、缓存策略、缓存穿透、击穿、雪崩

消息队列

• 问题：服务间耦合度高，同步调用容易导致系统阻塞。
• 解决方案：引入消息队列，实现异步通信。
• 技术调整：消息中间件、异步处理、流量削峰

分布式事务

• 问题：需要保证多个服务间的事务一致性。
• 解决方案：引入分布式事务解决方案。

监控与日志

• 问题：分布式系统复杂度高，难以监控和排查故障。
• 解决方案：引入监控系统和日志系统
• 技术调整：监控指标、日志收集、告警系统

redis分布式锁

RedLock算法是 Redis 官方支持的分布式锁算法。

• 互斥（只能由一个客户端获取锁）
• 不能死锁
• 容错（只要大部分 Redis 节点创建了这把锁就可以）

最普通的实现方式，是使用SET key value [EX seconds|PX milliseconds] NX创建一个key，就算加锁成功

• EX seconds：设置key的过期时间。seconds秒后锁自动释放，被人创建的时候发现已经有了就不能加锁了
• PX milliseconds：设置key的过期时间，精确到毫秒级
• NX：只有key不存在的时候才会设置成功，如果存在这个key，则会设置失败
  释放锁一般可以用lua脚本删除：

-- 删除锁的时候，找到key对应的value，与传过去的value做比较，如果是一样的才删除
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

考虑到 Redis 单实例会出现单点故障风险；或者普通主从异步复制，如果主节点挂了，key 还没有同步到从节点，此时从节点切换为主节点，别人就可以 set key，从而拿到锁。

RedLock 算法
假设有一个 Redis cluster，有5个 Redis master 实例。然后执行如下步骤获取一把锁：

1. 获取当前的时间戳，单位是毫秒
2. 轮流尝试在每个 master 节点创建锁，超时时间较短（客户端为了获取锁使用的超时时间比自动释放锁的总时间要小）
3. 尝试在大多数节点上建立一个锁，比如5个节点就要求3个节点
4. 客户端计算加锁的时间，如果建立锁的时间小于超时时间，就算建立成功了
5. 要是加锁失败，就依次之前建立过的锁删除
6. 只要别人建立了一把分布式锁，你就地不断轮询去尝试获取锁

分布式事务如何解决？

• 2PC 两阶段提交(准备，提交/回滚)

  1. prepare：所有参与者锁资源，准备好后向事务管理器报告。
  2. commit/rollback：事务管理器确认所有参与者都准备好后，向所有参与者发送commit命令，有问题就会滚。

• TCC（尝试、确认、取消）

  1. Try：尝试执行，完成所有业务检查，预留必须的业务资源。
  2. Confirm：确认执行，只使用Try阶段预留的业务资源，Confirm操作要有幂等性设计，失败后需要进行重试。
  3. Cancel：取消执行，释放Try阶段预留的业务资源。要有幂等性

  优点：控制数据库操作的粒度，降低了锁冲突，提升性能；
  缺点：侵入性强，根据网络、系统故障等不同失败原因实现不同的回滚策略，实现难度大。

• SAGA

  核心思想是将长事务拆分成多个本地短事务，由Saga事务协调器协调，如果正常结束就完成；若某个步骤失败，则根据相反顺序依次调用补偿操作。

• 本地消息表：写本地消息和业务操作放在一个事务里，保证业务和发消息的原子性，要么全部成功，要么全部失败。

• 事务消息：本质是把本地消息表放到 RocketMQ 上，解决生产端消息发送与本地事务执行的原子性问题。

• 最大努力通知

• 二阶段消息：参考 DTM 框架

具体参考分布式事务的七种解决方案

分布式接口幂等如何处理？

核心思想：通过唯一的业务单号保证幂等性，非并发情况下，查询业务单号有没有操作过，没有则执行操作；并发情况下，此过程需加锁。

• Update操作的幂等性

根据唯一业务号取更新数据：通过版本号来控制。用户查询出要修改的数据，系统将数据返给页面，将数据版本号放入隐藏域，用户修改数据提交时将版本号一同提交，后台使用版本号作为更新条件

update set version=version+1, xxx=${xxx} where id=xxx and version=${version};

• 使用 Token 机制，保证 update、insert 操作的幂等性

没有唯一业务号的 update 与 insert 操作：进入到注册页时，后台统一生成 Token，返回前台隐藏域中，用户在页面提交时将 Token 一同传入后台，使用 Token 获取分布式锁，完成 insert 操作，执行成功后不释放锁，等待过期自动释放。

容器化部署

K8s

Kubernetes 是一个开源的容器编排系统，用于自动化部署、扩展和管理容器化应用。K8s 作为应用服务与服务器之间的中间层，通过策略协调和管理多个应用服务，简化部署流程，实现自动扩缩容，并能在服务器出问题时自动重新部署应用。

要点：

• YAML 配置文件简化服务部署，包括应用部署顺序、内存CPU需求等。
• 控制平面的组成部分有：API Server提供API接口，Scheduler负责调度，Control Manager管理服务，Etcd存储数据。
• 工作节点Node：运行实际的应用程序，使用容器镜像简化部署，并通过容器运行时组件拉取镜像。
• Pod 是K8s中的最小调度单位，包含一个或多个容器，以及日志收集和监控采集组件。
• K8s通过 kubectl 命令行工具调用API，自动完成服务的部署和扩缩容。
• Ingress 控制器提供了外部用户访问K8s集群内部服务的入口。
• 控制平面和工作节点共同构成集群，各节点间可进行服务调度和网络通信。

可视化平台 KubeSphere

DDD

战略设计 (Strategic Design)

战略设计主要关注的是从业务角度理解问题域，并为软件系统划定合理的边界。你需要弄清楚以下几点：

1. 领域 (Domain):
   
   • 定义: 你需要理解什么是领域，它代表了组织所从事的业务范围和知识体系。
   • 重要性: DDD 的核心是围绕业务领域进行建模。
2. 子域 (Subdomain):
   
   • 定义: 领域通常很大且复杂，需要将其划分为更小、更易于管理的子域。
   • 类型：
     
     • 核心域 (Core Domain): 这是组织业务的核心竞争力，需要投入最多的精力进行精确建模和创新。
     • 支撑子域 (Supporting Subdomain): 这些子域支持核心域，但不直接构成核心竞争力。通常可以自研或购买成熟的解决方案。
     • 通用子域 (Generic Subdomain): 这些子域是多个业务都需要的通用能力，例如身份认证、权限管理、日志记录等。通常可以直接采用成熟的第三方库或服务。
3. 限界上下文 (Bounded Context):
   
   • 定义: 限界上下文是领域模型语义边界。在一个限界上下文中，模型中的术语和概念具有明确的、统一的含义。
   • 重要性: 避免模型在大型系统中变得混乱和不一致。每个团队在一个限界上下文中工作，拥有自己的模型。
   • 识别: 学习如何识别限界上下文，通常通过业务流程、团队组织结构、技术边界等因素来划分。
4. 上下文映射 (Context Mapping):
   
   • 定义: 上下文映射描述了不同限界上下文之间如何相互集成和协作。
   • 常见模式:
     
     • 共享内核 (Shared Kernel): 多个限界上下文共享一部分模型。
     • 客户方-供应方 (Customer-Supplier): 一个限界上下文依赖于另一个限界上下文提供的服务。
     • 顺从者 (Conformist): 下游限界上下文完全遵循上游限界上下文的模型。
     • 防腐层 (Anti-corruption Layer): 在两个限界上下文之间引入一个中间层，以防止外部模型的变更影响到内部模型。
     • 开放主机服务 (Open Host Service): 一个限界上下文明确定义并暴露其服务接口。
     • 发布-订阅 (Published Language): 使用通用的、文档化的语言进行限界上下文之间的通信。
     • 分离方式 (Separate Ways): 两个限界上下文之间没有直接的集成。

战术设计 (Tactical Design)

战术设计关注的是如何在单个限界上下文内部构建领域模型。你需要弄清楚以下几点：

1. 实体 (Entity):
   
   • 定义: 具有唯一标识符并且生命周期中会发生状态变化的对象。
   • 特点: 通过标识符来区分不同的实体，即使它们的属性值相同。
2. 值对象 (Value Object):
   
   • 定义: 没有唯一标识符，通过其属性值来识别的对象。值对象是不可变的。
   • 特点: 相同的属性值代表相同的对象，通常用于描述事物的属性或特征。
3. 聚合 (Aggregate):
   
   • 定义: 一组相关对象的集合，被视为一个独立的单元。聚合有一个根实体（Aggregate Root），外部只能通过根实体访问聚合内部的对象。
   • 目的: 维护数据的一致性和业务规则的完整性。
   • 设计原则:
     
     • 选择一个根实体作为聚合的入口。
     • 确保聚合内部事务的一致性。
     • 尽量减少聚合之间的引用。
4. 领域服务 (Domain Service):
   
   • 定义: 当某个重要的业务逻辑不属于任何实体或值对象时，可以将其封装到领域服务中。
   • 特点: 通常是无状态的，专注于执行特定的业务操作。
   • 使用场景: 涉及多个实体或值对象的协作，或者执行与领域概念相关的操作，但不适合放在实体或值对象内部。
5. 仓储 (Repository):
   
   • 定义: 提供一种抽象的方式来访问领域对象，隐藏底层数据访问的细节（例如数据库操作）。
   • 职责: 负责对象的持久化和检索。
   • 接口定义: 通常为每个聚合定义一个仓储接口。
   • 实现: 可以使用 ORM 框架或其他数据访问技术来实现仓储接口。
6. 工厂 (Factory):
   
   • 定义: 用于创建复杂领域对象或聚合的机制，将对象的创建逻辑从客户端代码中分离出来。
   • 作用: 隐藏对象的创建细节，保证对象创建的正确性。
7. 领域事件 (Domain Event):
   
   • 定义: 代表领域中发生的有意义的事件，用于在限界上下文内部或之间传递信息，实现松耦合。
   • 特点: 通常是过去时，描述已经发生的事情。
   • 作用: 促进不同模块或限界上下文之间的协作。

面试问题

什么是 DDD？它的核心价值是什么？

DDD 是一种以领域知识为驱动的软件设计方法。DDD 的核心价值在于：

• 聚焦业务领域： 将软件开发的核心放在理解和建模业务上。
• 促进沟通协作： 通过统一语言连接业务专家和开发人员。
• 管理复杂性： 提供应对复杂业务逻辑的方法和模式。
• 提高软件质量： 构建出更易于理解、维护和演进的软件系统。

请解释一下核心域、支撑子域和通用子域的区别和应用场景。

什么是限界上下文？如何划分限界上下文？

请解释一下共享内核、客户方-供应方和防腐层等上下文映射模式。

实体和值对象有什么区别？在什么情况下应该使用它们？

什么是聚合？聚合根的作用是什么？设计聚合时需要注意哪些方面？

什么是领域服务？它与实体方法有什么区别？

仓储的职责是什么？如何设计仓储接口？

仓储 (Repository) 充当领域模型与数据持久化机制之间的中介。设计仓储接口的关键在于：

• 抽象数据访问： 让领域模型专注于业务逻辑。
• 面向领域： 操作领域对象而不是数据结构。
• 表达业务意图： 提供符合业务需求的查询方法。
• 保持接口纯粹： 避免泄露底层实现细节。

什么是领域事件？它在 DDD 中有什么作用？

业务上重要的状态变更或发生的事实，可能触发领域内或其他界限上下文中的进一步行动。

• 解耦： 实现限界上下文内部和之间的松耦合。
• 集成： 支持不同限界上下文之间的异步通信。
• 记录： 作为领域状态变化的审计日志。
• 驱动： 触发后续的业务流程和操作。
• 可测试性： 提高核心领域模型的可测试性。
• 业务理解： 帮助更好地理解和表达业务行为。

其他

工作流 VS 规则引擎

调优

影响系统响应慢的原因有哪些？如何排查和解决的？

1. 慢SQL
2. 系统负载过高
3. Full GC 次数过高
4. 程序异常，死锁等
5. 网络原因

参考 Java问题排查

Tomcat 调优

WebSocket

JSR-356 规范，即 Javax WebSocket，定义了 Java 针对 WebSocket 的 API，主流的 Web 容器都已经提供了 JSR-356 的实现，例如说 Tomcat、Jetty、Undertow 等等。

目前提供 WebSocket 服务的项目中一般有几种方案：

• Tomcat WebSocket，实现简单
• Spring WebSocket，整合了 SockJS、实现了对浏览器的兼容，支持 stomp + 消息队列代理
• Netty WebSocket，性能好，可同时支持其他协议
• Socket.IO，类似于SocketJS实现浏览器兼容、负载均衡等，最初是 nodejs，Java 可通过 netty-socketio 包使用

一般非 IM 即时通讯项目，使用前两种都可以。具体参考：

• Spring WebSocket简析
• java 实现websocket的两种方式
• WebSocket实现鉴权方案
• Spring Boot接入WebSocket和Stomp
• WebSocket 集群方案
• GoEasy Websocket消息推送

断线重连

为何会断线？

• 进程被杀死
• 主动退出
• 后台挂起
• 页面断线重连
• 断网 此情况服务端无法感知

如何判断在线、离线？

1. 当客户端第一次发送请求到服务端是会携带唯一标识、时间戳，服务端到数据库/缓存中去查询请求的唯一标识，如果不存在就入库；
2. 第二次客户端定时再次发送请求携带唯一标识、时间戳，服务端查询唯一标识，如果存在就把上次的时间戳拿出来，判断间隔毫秒数是否大于指定时间，小于就是在线，否则就是离线；

如何解决断线问题？

• 可能是 nginx 配置的问题
• 心跳检测

客户端心跳检测:
1. 客户端定时通过管道发送心跳，发送时启动一个超时定时器
2. 服务端接收到心跳包，应答一个pong
3. 如果客户端收到服务端的应答包，则说明服务端正常，删除超时定时器
4. 如果客户端的定时器超时依然没有收到应答包，说明服务端挂了

服务端心跳检测：
1. 客户端定时通过管道发送心跳
2. 服务端记录每个用户最后一次心跳时间，并配置一个心跳最大间隔时长
3. 开启一个定时任务，根据每个用户最后一次心跳间隔时间和最大间隔时长来判断用户是否断线
4. 遇到超过最大间隔时长的直接剔除会话

如何保证消息一定送达给用户？

基于滑动窗口 ACK 。整体流程如下：

• 无论客户端是否在线，服务端都先把收到的消息持久化到数据库。如果客户端此时在线，服务端将消息编号推送给客户端。
• 客户端在接收到消息编号之后，和本地消息编号比对。如果比本地的小，说明该消息已经收到，忽略不处理；如果比本地的大，使用本地消息编号向服务端拉取大于本地消息编号的消息列表(增量消息列表)。拉取完成后，更新消息列表中最大的消息编号为新的本地的消息编号。
• 服务端在收到客户端拉取增量的消息列表时，将请求的编号记录到数据库中，用于知道客户端此时本地的最新消息编号。
• 考虑到服务端将消息编号推送给客户端，也会存在丢失的情况，所以客户端会每 N 秒定时向服务端拉取大于本地的消息编号的消息列表。

这种方式，在业务被称为推拉结合的方案。此种方案客户端和服务端不一定需要使用长连接，也可以使用长轮询所替代。客户端发送带有消息版本号的 HTTP 请求到服务端。

• 如果服务端已有比客户端新的消息编号，则直接返回增量的消息列表。
• 如果服务端没有比客户端新的消息编号，则 HOLD 住请求，直到有新的消息列表可以返回，或 HTTP 请求超时。
• 客户端在收到 HTTP 请求超时时，立即又重新发起带有消息版本号的 HTTP 请求到服务端。如此反复循环，通过消息编号作为增量标识，达到实时获取消息的目的。

线上故障

服务器监控哪些指标最需要关注？为什么？

• CPU 使用率：使用率过高表示服务器正在高负载运行，可能导致相应变慢甚至崩溃。平均/峰值使用率、CPU负载。
• 内存使用率：过高可能导致程序变慢甚至崩溃。可用内存、已用内存、内存泄漏。
• 磁盘空间使用率：重点关注已使用空间、可用空间、磁盘I/O。
• 网络流量
• 响应时间：过长会影响用户体验。
• 连接数：过高可能导致服务器负载过重。重点关注当前连接数、峰值连接数。
• 错误率：过高意味着程序可能存在问题。

故障1

事故情况：由于redis内存报警，导致接口失败率上升（没有配置redis拒绝策略，接口阻塞）。询问发现是上游同事进行了发布，于是迅速回滚，同时增大redis内存。
措施：让上游服务回滚；对redis扩容增大内存
事故原因：上游服务的对账系统调用自己的接口

1. 没有考虑到对账数据范围（进行了全量对账，存在冷数据）
2. 在业务高峰时期对账
3. 自己redis没有设置合理的淘汰策略

故障2：OOM

事故情况：MQ消费者服务OOM，致使服务直接挂掉
措施：重启服务，先暂时恢复
事故定位：查看 prometheus 上的服务监控，从某时刻开始内存明显飙升 && dump内存快照

1. 根据时刻判断业务操作，当时正在执行导入导出excel
2. 服务没挂，使用jmap -dump:live,format=b,file=/tmp/dump.hprof PID
3. 服务已挂：需提前配置 JVM 自动 dump-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/app/oom
4. 打开 VisualVM 分析发现org.apache.poi.xssf.usermodel.XSSFSheet类的对象占用的内存是最多，与之前推测吻合。找到相关代码

XSSFWorkbook wb = new XSSFWorkbook(new FileInputStream(file));
XSSFSheet sheet = wb.getSheetAt(0);

解决：改用 SXSSFWorkbook

XSSFWorkbook wb = new XSSFWorkbook(new FileInputStream(file));
SXSSFWorkbook swb = new SXSSFWorkbook(wb,100);//使用SXSSFWorkbook包装，一次读入内存100条记录
SXSSFSheet sheet = (SXSSFSheet) swb.createSheet("sheet1");
//省略中间代码
sheet.flushRows();

后续思考：使用 EasyExcel。MQ异步导入excel，并发量大的话仍然会出现OOM，有安全隐患，调整mq消费者线程池，设置成4个线程，避免消费者同时处理过多消息、

故障3：内存占用高

事故情况：有个服务内存使用率不断飙高，主要逻辑就是消费MQ的数据然后持久化
措施：重启应用，但无果
事故定位：查看监控数据发现老年代内存发生 GC 也一直居高不下，查看jstat日志发现老年代内存回收不了。尝
试在本地复现。

1. 调小JVM内存，消费MQ数据处使用while循环不断生成数据
2. VisualVM 连上应用实时监控内存、GC 的使用情况，跑十几分钟并未发现相同问题
3. 检查代码逻辑，发现逻辑是批量一次几百条数据
4. 修改模拟逻辑发现GC飙高，内存无法回收，问题复现
5. dump堆内存使用情况，发现com.lmax.disruptor.RingBuffer对象内存占用很大
6. 消费MQ数据一次取几百条数据扔给RingBuffer，考虑到扔给RingBuffer上的数据只有被覆盖了才会回收掉内存，检查RingBuffer配置1024*1024，目测是这的问题

解决：调小 Disruptor 的 RingBuffer 配置，调整到多少得根据业务具体情况配置

故障4：CPU飙高

事故情况：生产某个服务版本升级的时候，实例拉起后CPU占用飙高触发报警，响应缓慢。鉴于k8s配置的是滚动更新，导致响应缓慢持续了10分钟左右
措施：发布改到周末或晚上请求少的时候
事故定位：由于其他服务发布没有出现这种现象，考虑是不是应用版本有问题。后与开发确认版本没问题，进入容器中在线定位，
1. top找出 CPU 占用最高的 PID
2. ps -ef | grep PID何查看对应的应用
3. jstack -l PID >> PID.log获取进程堆栈信息
4. ps -mp PID -o THREAD,tid,time拿到占用CPU最高的 tid
5. printf "%x\n" tid获取16进制的线程 TID
6. grep TID -A20 PID.log确定是线程哪里出了问题
发现有几个C2 ComilerThread线程 CPU 占用比较高，但这几个不是应用线程。

Java 把编译过程分为两个阶段：编译期(javac编译成通用的字节码)、运行期(解释器逐条将字节码解释为机器码来执行)。
为了优化，HotSpot 引入了 JIT 即时编译器：
- 解释器：当程序启动时使用解释器快速执行，节省编译时间
- JIT编译器：程序启动后长时间提供服务时，JIT将越来越多的代码编译为本地机器码，获得更高的执行效率。
由于应用重启，大量的代码被识别为热点代码，触发了即时编译，造成CPU使用率飙高。

解决：jdk1.8默认打开分层编译，有一下几种办法
- 关闭分层编译：-XX:-TieredCompilation -client关闭分层编译，效果不好
- 预热：提前录制流量/流量控制预热/龙井预热(Jwarmup功能)
- 调高JIT阈值：-XX:CompileThreshold=5000修改JIT编译阈值为5000，资源不多的话可以使用
- 调整服务资源上限：调大CPU的limit，需要CPU就给够。有资源可以弹性的话可以使用

故障5：Netty内存泄露

事故情况：服务内存缓慢增长，CPU正常
措施：重启服务会好点，但依旧缓慢增长
事故定位：长时间的缓慢增长，说明GC回收不了，感觉像是内存泄漏

1. 查看ERROR日志，发现有 LEAK 字样，ByteBuf 分配的堆外内存，GC不能释放

   ByteBuf.release（） 在垃圾回收之前没有被调用。启用高级泄漏报告以找出泄漏发生的位置。要启用高级泄漏报告，请指定 JVM 选项“-Dio.netty.leakDetectionLevel=advanced”或调用 ResourceLeakDetector.setLevel（）

2. 本地复现，调整非堆内存大小-XX:PermSize=30M、-XX:MaxPermSize=43M，用Postman定时批量发请求，以达到服务的堆外内存泄漏。

3. 开启Netty的高级内存泄漏检测级别：-Dio.netty.leakDetectionLevel=advanced，查看泄露日志
4. 定位具体代码。

解决办法：

• 手动释放
• 升级ChannelHandler为SimpleChannelHandler，在SimpleChannelHandler中，Netty对收到的所有消息都调用了ReferenceCountUtil.release(msg)
• 使用Netty的ReferenceCountUtil.release(msg)来释放，这个方法会判断上下文是否可以释放，稳妥

亮点

Excel 导入导出

详细参考：百万级数据excel导出功能如何实现？
导入功能比导出麻烦点，需要各种校验，留出接口方便业务校验扩展

多平台统一的消息推送系统

Server服务主要维护客户端的长连接，它能力决定了一次可以在线多少用户。需要集群部署。
Route服务负责将消息分发到各个平台

客户端连接Server服务的流程：

1. 客户端问路由服务要一个可用的Server服务器IP+端口
2. 路由服务通过合适的负载均衡算法得到一个Server服务器ip+端口，返回给客户端
3. 客户端向拿到的Server服务发起长连接
4. 连接成功后，对应的Server服务器维护服务级别的session信息，然后向路由服务汇报，路由服务保存该客户端和Server服务的对应关系
5. 客户端与对应的Server服务保持一定频率的心跳，并在心跳失败判定连接断开后重新发起连接，直到连接成功

客户端上线后，向其他客户端投递消息的流程：
1. 客户端请求路由服务提供的消息投递接口
2. 路由服务根据消息上的目标客户端id，找到对应的Server服务，并向该服务投递消息
3. Server服务从自己维护的socket里找到目标客户端，最终完成消息投递

Q：路由服务如何通过负载均衡算法找到一个可用的socket服务器ip和端口？
A：socket服务提供一个查询本机ip和端口的接口，路由服务请求此接口时通过自定义的负载均衡算法选择一个可用的服务器ip和端口

Q：消息投递的时候，路由服务如何根据目标客户端id找到对应的server服务？
A：在客户端与某个server服务连接成功(上线)后，客户端与server服务之间的关系需要保存(数据库/redis)。然后写一个feign的拦截器，根据目标客户端的id获取server服务id，加到当前线程里

Q：如何优化性能
A：路由服务要承担路由、上下线、消息推送及其他业务，因此服务内部使用了Disruptor环形队列做异步处理，尽可能让消息推送接口更快返回。如果并发量比较高，可以加入消息队列，路由服务直接消费消息，以此来提升服务整体性能。

系统设计(System design)

网关系统

参考：https://mp.weixin.qq.com/s/tl4D4Kc7r4wL7aouQYZC4g