1. Java
   1. Concurrency
      1. Baeldung Java Concurrency
      2. 马士兵50道面试多线程题
      3. Java多线程与并发系列22道高频面试题
      4. 锁机制实现方式
         1. synchronized
         2. volatile
         3. ThreadLocal
         4. ReentrantLock
            1. Condition
         5. java.util.concurrent
         6. Synchronizers
            1. Semaphores
            2. CountDownLatch
            3. CyclicBarrier
            4. Phaser
            5. Exchanger
            6. SynchronousQueue
         7. 原子类
            1. AtomicInteger
            2. AtomicBoolean
      5. Questions
         1. 线程的状态有几种？
            1. 新建(New)
            2. 运行(Runnable)
            3. 无限期等待(Waiting)
            4. 限期等待(TimedWaiting)
            5. 阻塞(Blocked)
            6. 结束(Terminated)
         2. sleep、yield、wait、join的区别？
   2. JVM
      1. 故障排查/性能分析
         1. 分析JVM堆转储快照文件（hprof文件）
            1. -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/export/Domains/rcsv-fm.wd.local/server1/logs
            2. Eclipse Memory Analyzer 分析hprof文件
      2. 77道JVM系列面试题总结
      3. 底层原理
         1. 64位虚拟机的指针压缩是什么？为什么要指针压缩？
            1. 对齐填充（Padding）
            2. -XX:+UseCompressedOops
   3. 基础
      1. 静态变量final和不final的区别？
         1. 有final修饰的情况下，其对象值必须在声明的时候初始化且不可在编译期或运行期被修改
         2. 在类加载阶段，读取或设置一个类型的静态字段（没被final修饰）需要先触发其初始化阶段，如果是已经被final修饰的对象，其类加载初始化阶段是在虚拟机加载final字段所在类的时候触发
         3. 使用final关键字修饰变量就可以保证它是不可变的
         4. 被final修饰的类不可以被继承
         5. 被final修饰的方法不可以被重写
      2. Java创建对象有几种方式
         1. new
         2. 通过反射机制
         3. 采用clone机制
         4. 通过序列化机制
      3. 深拷贝 VS 浅拷贝
         1. Java深拷贝和浅拷贝
         2. Java如何对一个对象进行深拷贝?
         3. How to Make a Deep Copy of an Object in Java
      4. 面向对象
         1. 特性
            1. 封装
            2. 继承
            3. 多态
         2. 将我们编程当中的业务场景都给对象化，这样子开发的软件系统相对面向过程的编程来说，更加易维护、易复用、易扩展，可以设计出低耦合的系统
      5. 基础数据
         1. 字符串
            1. StringBuffer VS StringBuilder
            2. 他们的底层都是可变的字符数组，所以在进行频繁的字符串操作时，建议使用StringBuffer和StringBuilder来进行操作。另外StringBuffer 对方法加了同步锁或者对调用的方法加了同步锁，所以是线程安全的。StringBuilder 并没有对方法进行加同步锁，所以是非线程安全的
      6. transient
         1. transient是在对象序列化的时候，不参与序列化的字段
      7. 集合
         1. ArrayList VS LinkedList
            1. 读写速度各自的优劣
            2. 一个基于数组元素，一个是基于双向链表结构实现
         2. HashMap VS HashTable
            1. HashTable的key和value都不能为null，HashMap的key可以为null，但是这样的key只能有一个，因为必须保证key的唯一性；可以有多个key值对应的value为null
            2. HashTable是相对线程安全的，HashMap非也
            3. HashTable每个方法上都有synchronized 关键字，当需要多线程操作的时候可以使用线程安全的ConcurrentHashMap，ConcurrentHashMap的锁粒度没有HashTable的粗，只在关键地方做必要的锁同步
2. 微服务
   1. 50个微服务面试问题
   2. Ribbon或者Nacos负载均衡有多少种实现机制？
      1. 轮询 （round-robin）
         1. 适用于服务器性能相近的集群情况，其中每个服务器承载相同的负载
      2. 加权轮询
         1. 加权轮询可以应用于服务器性能不等的集群中，使资源分配更加合理化
      3. IP 哈希（IP hash）
         1. 在一定程度上解决了集群部署环境下 Session 不共享的问题
   3. 如果是多个微服务之间要实现同步锁进行某个数据的操作更新，可以借助redis进行标记上锁
      1. 某个微服务对某一唯一数据做同步操作时上锁（可以用hashmap数据结构标志上锁），其他微服务要等待锁释放
   4. 架构
      1. 垂直拆分和微服务分布式拆分的区别？
         1. 最重要的区别是垂直式拆分的各个子系统之间没有交互，都是直接与数据库交互，而微服务分布式的各个子系统时刻错终复杂地进行各种业务交互，解耦和扩展相对来说都比较便捷和清晰明了
         2. 微服务的优点
            1. 独立开发
            2. 独立部署
            3. 故障隔离
            4. 出现故障的微服务可以降级熔断
            5. 混合技术堆栈
            6. 粒度缩放
            7. 单个组件可根据需要进行缩放，无需将所有组件缩放在一起
   5. 注册中心
      1. 注册中心的作用是什么？
      2. Eureka VS Nacos
         1. eureka对要新注册进来的微服务感知比较慢，一个服务启动完有可能要等上几十秒才能被发现。
      3. 注册中心的实现机制
3. Spring
   1. Spring系列面试题129道
   2. Baeldung的Spring系列文章
   3. Basic
      1. Bean生命周期
         1. 创建bean的实例
         2. 给实例化出来的bean填充属性
         3. 初始化Bean
         4. 通过IOC容器使用我们DI到各个类的Bean
         5. 容器关闭时销毁Bean
      2. 循环依赖
         1. N个类互相嵌套（DI）引用，形成闭环
         2. 解决方法
            1. 可以提到Mapper、Service类的单一职责原则，多个表混合的业务逻辑抽到OperateService
      3. 一级缓存、二级缓存和三级缓存
         1. singletonObjects
            1. 第一级缓存，存放可用的完全初始化，成品的Bean
         2. earlySingletonObjects
            1. 第二级缓存，存放半成品的Bean，半成品的Bean是已创建对象，但是未注入属性和初始化
         3. singletonFactories
            1. 第三级缓存，存的是Bean工厂对象，用来生成半成品的Bean并放入到二级缓存中。如果Bean存在AOP的话，返回的是AOP的代理对象
      4. Spring Transaction的事务传播行为
         1. PROPAGATION_REQUIRED
            1. 默认的spring事务传播级别，使用该级别的特点是，如果上下文中已经存在事务，那么就加入到事务中执行，如果当前上下文中不存在事务，则新建事务执行。所以这个级别通常能满足处理大多数的业务场景
         2. PROPAGATION_SUPPORTS
            1. 支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就以非事务执行
         3. PROPAGATION_MANDATORY
            1. 支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常
         4. PROPAGATION_REQUIRES_NEW
            1. 创建新事务，无论当前存不存在事务，都创建新事务
         5. PROPAGATION_NOT_SUPPORTED
            1. 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起
         6. PROPAGATION_NEVER
            1. 以非事务方式执行，如果当前存在事务，则抛出异常
         7. PROPAGATION_NESTED
            1. 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作
      5. SpringMVC
         1. SpringMVC请求流程
            1. 请求的入口最先到达DispatchServlet，通过一个处理映射器（HandleMapping）找到请求路径对应的Controller，然后再将请求转到Controller里面去做具体的处理
         2. HandlerInterceptor什么时候被触发？
            1. 通过配置请求的URL路径，可以通过通配符的方式配置，在通过URL请求到对应的Controller之前会触发拦截器
            2. preHandle
            3. 请求处理之前进行调用
            4. postHandle
            5. 在当前请求处理之后进行调用，也就是Controller 方法调用之后执行
            6. afterCompletion
            7. 需要当前对应的Interceptor的preHandle方法的返回值为true 时才会执行
4. Mybatis
   1. 一级缓存VS二级缓存
   2. Mybatis Plus
5. Springboot
   1. SpringBoot自动装配原理
   2. 官方文档大概一遍
6. Spring Cloud
   1. Springcloud用来做什么的？
   2. Spring Cloud面试题
   3. Spring Cloud Stream
      1. 应用的业务场景
         1. 日志处理
            1. 生产者端发送日志的原生数据
            2. 消费者端接收原生数据格式化处理之后输出，将处理过的日志存储起来
   4. Spring Cloud Alibaba
      1. Nacos
      2. Sentinel
         1. 流量削峰
         2. 服务降级和熔断
      3. Dubbo
         1. 服务调用
      4. Seata
         1. 分布式事务
7. 数据库
   1. MySQL
      1. 我自己总结的博文
         1. Mysql系列之基础知识
         2. Mysql系列之性能优化与问题定位
      2. 阿里巴巴MySQL规范
      3. 存储引擎
         1. MyISAM
            1. 不支持事务，但是每次查询都是原子性的，适合做报表，或者一些只有查询操作的数据库
         2. InnoDB
            1. Mysql默认
      4. 锁机制
         1. 行级锁
            1. 锁的类型
            2. 共享锁 （也称为 S 锁）
            3. 独占锁 （也称为 X 锁）
            4. 意向共享锁 （IS）
            5. 意向排他锁 （IX）
            6. 行锁的算法
            7. Record Locks
            8. 该锁为索引记录上的锁，如果表中没有定义索引，InnoDB 会默认为该表创建一个隐藏的聚簇索引，并使用该索引锁定记录
            9. Gap Locks
            10. Next-key Locks
         2. 死锁
         3. 锁的优化建议
         4. 表级锁
         5. 页面锁
   2. combos
      1. 怎么防止SQL注入
      2. 数据库连接池的问题
      3. 事务的四个特性
         1. 原子性 （Atomicity）
         2. 一致性 （Consistency）
         3. 隔离性 （Isolation）
         4. 持久性 （Durability）
      4. 事务隔离级别和传播性
         1. 隔离级别
            1. Serializable（串行化隔离）
            2. 最严格的级别，事务串行执行，资源消耗最大
            3. REPEATABLE READ（可重复读）
            4. 在同一个事务里， select 的结果是事务开始时时间点的状态，因此，同事务的 select 操作读到的结果会是一致的
            5. READ COMMITTED（读提交）
            6. 一个事务可以读取另一个已提交的事务，多次读取会造成不一样的结果
            7. READ UNCOMMITTED（读未提交）
            8. 该隔离级别的事务会读到其它未提交事务的数据，此现象也称之为脏读
         2. 概念
            1. 脏读
            2. 读到其它未提交事务的数据，此现象也称之为脏读
            3. 幻读
            4. 一个事务读多次，出现的结果可能存在于真实数据不一致的情况，比如某个SQL第一次读取无记录，然后其他事务此时提交了某些数据（同个SQL可以查出来的），该SQL在同个事务之下再次读取还是无记录
            5. 不可重复读
            6. 一个事务可以读取另一个已提交的事务，多次读取会造成不一样的结果，此现象称为不可重复读问题
         3. MySQL 事务隔离级别和锁（IBM）
      5. 脏读、幻读与不可重复读
8. 缓存
   1. Redis
      1. Redis的11道面试题
      2. 缓存穿透，缓存击穿，缓存雪崩原因+解决方案
      3. 缓存穿透
         1. key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库
         2. 解决方案
            1. 如果一个查询返回的数据一直为空（不管是数据不存在，还是系统故障），我们可以把这个空结果进行缓存，但它的过期时间会很短，最长可以不超过五分钟、10分钟。
            2. 布隆过滤器
      4. 缓存击穿
         1. key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮
         2. 解决方案
            1. 使用互斥锁(mutex key)
            2. 在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法
      5. 缓存雪崩
         1. 当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力
         2. 与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key
         3. 解决方案
            1. 大多数系统设计者考虑用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上
            2. 将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件
            3. 设置过期标志更新缓存，同时增加缓存实际过期时间
            4. 缓存标记
            5. 记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际key的缓存
            6. 缓存数据
            7. 它的过期时间比缓存标记的时间延长1倍，这样，当缓存标记key过期后，实际缓存还能把旧数据返回给调用端，直到另外的线程在后台更新完成后，才会返回新缓存
      6. 高并发如何保证缓存与数据库的双写一致性？
         1. Cache Aside Pattern
            1. 读的时候，先读缓存，缓存没有的话，就读数据库，读完将数据一并同步到缓存里面，同时返回响应，更新的时候，先删除缓存数据，再更新到数据库，然后事务提交成功的话就能保证双写一致性
         2. 数据更新，缓存不一致问题
            1. 先更新数据库，再删除缓存。如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据就出现了不一致。
         3. 数据更新，先删除缓存再更新数据库，也会导致数据不一致问题
            1. 删除缓存之后去更新数据库期间，有个请求进来命中了空缓存和数据库的老数据
            2. 更新数据的时候，根据数据的唯一标识，将操作路由之后，发送到一个 jvm 内部队列中，也就是多个请求同时高并发对同一个数据做读取或更新要串行化
         4. 为什么是先删除缓存，而不是先更新缓存？
            1. 简单粗暴，如果取更新缓存的话可能会涉及一些关联的复杂逻辑，对于比较复杂的缓存数据计算的场景，如果更新的同时有读取同个缓存数据的高并发请求过来，这时候出现数据不一致的概率会更大，直接删除的相对来说比较快
            2. 确保数据一致，如果数据库更新失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致
9. Netty
10. 消息队列
    1. 生产者
    2. 消费者
11. Elasticsearch
    1. 研究完明博的es代码套路
12. 流程
    1. Flowable
       1. 研究下邹耀天流程的代码
13. 设计模式
    1. 创建型模式
    2. 结构型模式
    3. 行为型模式
       1. 观察者模式
14. 网络
    1. 协议
       1. TCP
          1. 三次握手
       2. UDP
       3. HTTP
          1. 短链接
          2. 无状态
          3. 应用层协议，基于传输层的TCP协议
       4. Socket
          1. 长链接
          2. 基于对TCP/IP的封装
          3. Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开
       5. HTTP是轿车，提供了封装或者显示数据的具体形式；Socket是发动机，提供了网络通信的能力。
    2. Cybersecurity
       1. Cross-site request forgery (CSRF)
15. 算法
16. IO/NIO（Input/Output）（New IO）
    1. 内存
       1. 操作系统内核（Kernel）
          1. GDT
             1. 保护模式
          2. Syscall（系统调用）
             1. 暴露一系列接口操作硬件
             2. 中断
             3. 软中断（用户程序的调用）
             4. 硬中断（鼠标、键盘操作的调用）
       2. 用户程序
          1. QQ、WeChat等
          2. Tomcat、Java等
       3. 内核内存空间，可以与硬件直接交互
       4. 用户程序内存空间，不可与硬件直接交互
    2. CPU
       1. 指令集
          1. Range0~3（级别）
             1. 内核是作用在指令集Range0级别上面的
             2. 用户程序间接使用的指令集是在Range3级别
    3. 命令
       1. strace（跟踪系统调用）
          1. -ff 抓取所有的线程
          2. 如果某个Java程序占用资源异常的多，也可以使用该命令快速简易地查看是否发生过多线程的创建
          3. 跟踪过程
             1. jps
             2. cd /proc/xxxx
             3. task目录
             4. 列出xxxx的jdk进程里面的所有的线程
             5. fd目录
             6. 任何一个程序至少有三个IO
             7. 标准输入0
             8. 标准输出1
             9. 错误输出2
          4. 同样可以用来跟踪Nginx、Redis等
    4. BIO
       1. 早期的IO方式，阻塞IO
       2. 弊端
          1. 每个客户端请求发生一系列系统调用
          2. 创建的线程太多，每个线程都要通过系统调用clone，系统调用太多，资源消耗太多
          3. CPU在进程或线程之间来回切换时间成本抬高
       3. O(n)复杂度
    5. NIO
       1. 相较BIO的改进之处
          1. 所有请求进来的客户端只汇总发生一遍系统调用
       2. 弊端
          1. 每次要传递给n个请求的所有数据给内核，内核在其内部要一下子去循环处理n个”数据包“，数据太多
          2. 内核要主动遍历拿到所有IO请求的返回结果，再交给用户程序去同步读取
       3. 弊端的改进方法
          1. 内核开闭一个空间，用来接收传递的请求数据，减少每次传递的过程
          2. 基于网卡到内存的事件驱动，准备一个内存空间，专门存放可读可写的IO返回结果供程序统一获取去同步读写
          3. epoll更充分发挥硬件资源，尽量不浪费CPU资源
       4. O(m)复杂度
          1. select(fds)
17. 软件测试
    1. 服务请求压力测试
       1. 使用Apache的Jmeter开了多个现场循环多次去调用查单词的接口
18. 全栈开发
    1. 前端技术
       1. Vue以及其生态
       2. 各种UI组件、图标库、请求组件和前端好用便捷的组件
19. 项目经验
    1. 贵州电信运维系统
       1. 系统业务模块
          1. 用户组织架构
          2. 权限管理
          3. 基础数据管理模块
             1. 字典
             2. 流水号配置
             3. 业务数据配置
          4. 策略引擎自定义流程
          5. 材料调拨分发子系统
          6. 工单流程化统一调度
          7. 通用树配置模块
       2. 平时的需求大概都是些什么？
       3. 技术栈
          1. 新版本
             1. 前端
             2. Vue、以及Vue生态的各种组件
             3. Element UI
             4. 一些自研的组件，用来自动去生成页面、表单和符合我们业务需求的常用工单操作
             5. 通过Web Socket通信
             6. 后端
             7. Spring Cloud 微服务架构
             8. 注册中心
             9. Spring Cloud Eureka
             10. Nacos
             11. 配置中心
             12. Spring Cloud Config
             13. Nacos
             14. 网关（Spring Cloud Gateway）
             15. API网关
             16. 路由
             17. 负载均衡
             18. 负载均衡（Spring Cloud Ribbon）
             19. 微服务调用（Restful）
             20. Spring Cloud Feign
             21. 断路器
             22. Spring Cloud Hystrix
             23. Spring cloud turbine
             24. 调用链路跟踪
             25. skywalking
             26. Spring Cloud Sleuth + Zipkin
             27. 基础设施
             28. 分布式缓存
             29. 分布式数据库
             30. Mysql
             31. MyCat
             32. 消息中间件
             33. RabbitMQ
             34. Kafka
             35. ES搜索引擎
             36. 分布式文件存储（FastDFS）
             37. 时序数据库（InfluxDB）
             38. Docker容器化部署、jenkins自动发布
             39. 分布式任务调度（XXL-JOB）
             40. 日志处理（ELK）
             41. 系统服务访问大致路径
             42. 外部请求 → 负载均衡 → 服务网关→ 微服务 → 数据服务/消息服务
    2. 江苏/上海/新疆电信综合调度系统
    3. 公司已经打算从传统的外包过度到SaaS模式了
    4. Kiwi词典
20. 开发运维
    1. Jenkins
    2. 灰度发布
    3. CI/CD
       1. 持续集成（CONTINUOUS INTEGRATION）
       2. 持续交付（CONTINUOUS DELIVERY）
    4. 敏捷交付
21. Combos
    1. COW（写时复制/Copy-on-write）
    2. 遇到问题一般都是怎么解决的？
       1. 最重要的还是先跟踪一些具体的报错信息，以前老是忽略了报错日志的细节，然后自己去想当然地跟代码排除故障，实际上应该第一时间点从错误日志切入才是最正确的做法
    3. 询问做过的系统中的QTS、TPS能达到多少的问题
       1. 可以拿我自己用Apache的Jmeter服务压力请求测试
    4. 平常经常看哪些编程的资讯、技术学习的渠道
       1. v2ex
       2. Spring官网
          1. spring.io
          2. Spring的blog
       3. Java
          1. How2J
          2. Baeldung
          3. Spring官网
             1. spring.io
             2. Spring的blog
          4. javatpoint
       4. Algorithm
          1. leetcode
          2. leetcode-cn
       5. tool
          1. alfred
             1. web search
             2. runoob
             3. dockerhub
             4. gh
             5. jce
             6. mvn
             7. sof
             8. baeldung