非八股文！Java面试刁钻夺命连环问汇总

equals() 相等的两个对象他们的 hashCode() 肯定相等，也就是用 equals() 对比肯是绝对可靠的。

hashCode() 相等的两个对象他们的 equals() 不一定相等，也就是 hashCode() 不是绝对可靠的。

为性能考虑：首先用 hashCode()去对比，hashCode 不一样则肯定不相等；hashCode 相等再对比 equals。

为了保证同一个对象，保证在 equals 相同的情况下 hashCode 值必定相同，如果重写了 equals 而未重写 hashCode，可能就会出现两个没有关系的对象 equals 相同（因为 equals 都是根据对象的特征进行重写的），但 hashCode 确实不相同的情况。

hashCode 和 equals 都是基本类 Object 里的方法，和 equals 一样，Object 里 hashCode 只是返回当前对象的地址，如果是这样的话，相同的一个类 new 两个对象，由于他们在内存里的地址不同，则他们的 hashCode 不同，所以这显然不是我们想要的。所以我们必须重写类的 hashCode 方法，即一个类，在 hashCode 里面返回唯一的一个 hash 值。

基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是也为计算机系统带来更高的复杂度，因为它引入了一个新的问题：缓存一致性（Cache Coherence），在多处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存（Main Memory），当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致。

重排序类型

数据依赖性

as-if-serial

控制依赖性

volatile 重排序规则表

volatile 的内存屏障

主内存-总线-CPU 工作内存，CPU 总线嗅探机制，某线程对主内存数据的修改（lock，其他线程无法读取修改），将工作内存中相同的内容失效。

lock 前缀指令

Store Barrier：sfence

Load Barrier：ifence

Full Barrier：mfence

Java 内存模型中 volatile 变量在写操作之后会插入一个 store 屏障，在读操作之前会插入一个 load 屏障。一个类的 final 字段会在初始化后插入一个 store 屏障，来确保 final 字段在构造函数初始化完成并可被使用时可见。

原子指令和 Software Locks

内存屏障的性能影响

在 Java 中使用 unsafe 实现 CAS，而其底层由 CPP 调用汇编指令实现的，如果是多核 CPU 是使用 lock cmpxchg 指令，单核 CPU 使用 compxch 指令。
如果在短时间内产生大量的 CAS 操作再加上 volatile 的嗅探机制则会不断地占用总线带宽，导致总线流量激增，就会产生总线风暴。
总之，就是因为 volatile 和 CAS 的操作导致 BUS 总线缓存一致性流量激增所造成的影响。

后台定时任务，例如：定时向大量用户（100w 以上）发送邮件。

异步处理，例如：发微博、记录日志等。

分布式计算

进程是程序运行资源分配的最小单位

线城是 CPU 调度的最小单位，必须依赖于进程而存在

线程无处不在

意义

优点

注意事项

synchronized、volatile、ThreadLocal 如何实现线程共享

wait/notify/notifyAll 如何实现线程之间的协作

分而治之

原理

实战

什么是原子操作？如何实现原子操作？

ABA 问题

循环时间长开销大

只能保证一个共享变量的原子操作

AtomicInteger

AtomicIntegerArray

更新引用类型

原子更新字段类

内置锁和显式锁

公平锁和非公平锁

锁的可重入

Lock 的标准用法

Lock 的常用 API

ReentrantLock

读写锁 ReentrantReadWriteLock

Condition 接口

扩展知识点

学习 AQS 的必要性

AQS 使用方法和其中的设计模式

Hash 算法

位运算

1.7 中 HashMap 死循环分析

使用

ConcurrentHashMap 实现分析

了解什么是 SkipList

什么是写时复制容器？

写时复制容器相关问题

队列

什么是阻塞队列

常用阻塞队列

了解阻塞队列的实现原理

手写阻塞队列

线程封闭

无状态的类

让类不可变

volatile

加锁和 CAS

安全的发布

ThreadLocal

Servlet 辨析

概念

现象、危害和解决

活锁

线程饥饿

线程引入的开销

如何减少锁的竞争

循环依赖

如何一次注入所有类

JDK 动态代理

CGLib 动态代理

事务失效

如何修改源码？
项目依赖的 xx 包，在工程下面创建一个同样的包名同样的类，然后进行相应的修改。
Java 线程在启动的时候，类加载会通过相应的顺序优先加载工程里的类。

Java 即时编译，字节码，JVM 检测到热点代码执行次数达到一定阈值之后，会编译成更底层的机器码，执行起来会更加高效。

下线，服务发现，类似于 zk 主动推拉的一种机制，包括缓存如何进行刷新（zk 不是一种强一致性，而是一种顺序一致性，写入其实是一种过半机制，没写入的节点其实数据还是老数据，它就可能调到已经下线的机器上），一个请求过来，如何知道哪个请求是对应哪一个响应呢？

TCP 这一层，解码、转码、序列化……

IO 模型，阻塞、非阻塞，异步、同步

如何降低拷贝数量

实现一致性
undolog 主要为事务的回滚服务。在事务执行的过程中，除了记录 redolog，还会记录一定量的 undolog。undolog 记录了数据在每个操作前的状态，如果事务执行过程中需要回滚，就可以根据 undolog 进行回滚操作。单个事务的回滚，只会回滚当前事务做的操作，并不会影响到其他的事务做的操作。
undolog 记录的是已部分完成并且写入硬盘的未完成的事务，默认情况下回滚日志是记录下表空间中的（共享表空间或者独享表空间）

undolog 是逻辑日志，根据每行记录进行记录

READ UNCOMMITTED

READ COMMITTED

REPEATABLE READ

SERIALIZABLE

RR 级别下 MVCC 如何工作

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

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

实现持久化和原子性
在 InnoDB 的存储引擎中，事务日志通过重做(redo)日志和 InnoDB 存储引擎的日志缓冲(InnoDB Log Buffer)实现。事务开启时，事务中的操作，都会先写入存储引擎的日志缓冲中，在事务提交之前，这些缓冲的日志都需要提前刷新到磁盘上持久化，这就是 DBA 口中常说的“日志先行”(Write-Ahead Logging)。当事务提交之后，在 Buffer Pool 中映射的数据文件才会慢慢刷新到磁盘。此时如果数据库崩溃或者宕机，那么当系统重启进行恢复时，就可以根据 redolog 中记录的日志，把数据库恢复到崩溃前的一个状态。未完成的事务，可以继续提交，也可以选择回滚，这基于恢复的策略而定。
在系统启动的时候，就已经为 redolog 分配了一块连续的存储空间，以顺序追加的方式记录 redolog，通过顺序 IO 来改善性能。所有的事务共享 redolog 的存储空间，它们的 redolog 按语句的执行顺序，依次交替的记录在一起。

redolog 是物理日志，记录页的物理修改操作

主从复制过程
数据的同步是通过 binlog 进行的。
两个线程：I/O 线程，SQL 线程

解决方式很简单，每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN。然后设置一个过期时间，这样的话，下次有相同的 key 来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。

不同场景下的解决方式可如下：
1. 若缓存的数据是基本不会发生更新的，则可尝试将该热点数据设置为永不过期。
2. 若缓存的数据更新不频繁，且缓存刷新的整个流程耗时较少的情况下，则可以采用基于 Redis、zookeeper 等分布式中间件的分布式互斥锁，或者本地互斥锁以保证仅少量的请求能请求数据库并重新构建缓存，其余线程则在锁释放后能访问到新缓存。
3. 若缓存的数据更新频繁或者缓存刷新的流程耗时较长的情况下，可以利用定时线程在缓存过期前主动的重新构建缓存或者延后缓存的过期时间，以保证所有的请求能一直访问到对应的缓存。

事前：
1. Redis 高可用，主从+哨兵，Redis Cluster，避免全盘崩溃。
2. 热点值设置不同的过期时间

事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。

事后：Redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

本地缓存

远程缓存

内存缓存

SSD 缓存

分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如，电商网站交易付款出现问题了，商品依然可以正常浏览。

由于不要求强一致性，BASE 允许系统中存在中间状态（或者叫软状态），这个状态不影响系统可用性，如订单的“支付中”“数据同步中”等，待数据最终一致后状态改为“成功”。

分类

指经过一点时间后，所有节点数据都将会达到一致。如订单的“支付中”状态，最终会变为“支付成功”或者“支付失败”，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。

阶段一
a) 协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复。
b) 各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）。
c) 如参与者执行成功，给协调者反馈 yes，否则反馈 no。

阶段二
如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息；否则，发送提交(commit)消息。

问题
1) 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。
2) 可靠性问题：如果协调者存在单点故障问题，或出现故障，提供者将一直处于锁定状态。
3) 数据一致性问题：在阶段 2 中，如果出现协调者和参与者都挂了的情况，有可能导致数据不一致。

优点：尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）。

缺点：实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

XA 方案：基于 XA 协议的两阶段提交
XA 是一个分布式事务协议，XA 中大致分为两部分：事务管理器（TM）和本地资源管理器（RM）。
其中本地资源管理器往往由数据库实现，比如 Oracle、DB2 这些商业数据库都实现了 XA 接口；
而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。

Seata 方案：基于阿里开源分布式事务框架 Seata
Seata 解决了传统 2PC 问题，通过对本地关系数据库的分支事务的协调来驱动完成全局事务，是工作在应用层的中间件。
目前提供 AT 模式（即 2PC）和 TCC 模式的分布式事务解决方案。
TC：Transaction Coordinator，事务协调器，是独立的中间件，需要独立部署运行（Seata 服务端），它维护全局事务的运行状态，接收 TM 指令发起全局事务的提交与回滚，负责与 RM 通信协调各分支事务的提交或回滚。
TM：Transaction Manager，事务管理器，TM 需要嵌入应用程序中工作（Seata 客户端，可以理解为一个 jar 包），它负责开启一个全局事务，并最终向 TC 发起全局提交或全局回滚的指令。
RM：Resource Manager，控制分支事务（Seata 客户端，可以理解为一个 jar 包），负责分支注册、状态汇报，并接收事务协调器 TC 的指令，驱动分支（本地）事务的提交和回滚。

阶段一
a) 协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复。
b) 参与者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。

阶段二
协调者根据参与者响应情况，有以下两种可能。

阶段三
该阶段进行真正的事务提交，也可以分为以下两种情况。

优点：相比二阶段提交，三阶段提交降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题。阶段 3 中协调者出现问题时，参与者会继续提交事务。

缺点：数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 doCommit 指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

TCC 事务补偿型方案
TCC 是 Try、Confirm、Cancel 三个词的缩写，TCC 要求每个分支事务实现三个操作：预处理 Try、确认 Confirm、撤销 Cancel。
Try 操作做业务检查及资源预留，Confirm 做业务确认，Cancel 实现一个与 Try 相反的操作即回滚操作。
TM 首先发起所有的分支事务的 try 操作，任何一个分支事务的 try 操作执行失败，TM 将会发起所有分支事务的 cancel 操作；若 try 全部成功，TM 将会发起所有分支事务的 confirm 操作，其中 confirm/cancel 操作若执行失败，TM 会进行重试。
TCC 分为三个阶段，具体如下：
1. Try 阶段是做业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，它和后续的 Confirm 一起才能真正构成一个完整的业务逻辑。
2. Confirm 阶段是做确认提交，Try 阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用 TCC 则认为 Confirm 阶段是不会出错的。即：只要 try 成功，Confirm 一定成功。若 Confirm 阶段真的出错了，需引入重试机制或人工介入处理。
3. Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用 TCC 则认为 Cancel 阶段一定是成功的。若 Cancel 阶段真的出错了，需引入重试机制或人工介入处理。
4. TM 事务管理器，可以实现为独立的服务，也可以让全局事务发起方充当 TM 的角色，TM 独立出来是为了成为公用组件，是为了考虑系统结构和软件复用。TM 在发起全局事务时生成全局事务记录 XID，XID 贯穿整个分布式事务调用链条，用来记录事务上下文，追踪和记录状态，由于 Confirm 和 Cancel 失败需进行重试，因此需要实现幂等。

可靠消息最终一致性方案
业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正的发送。业务处理服务在业务事务提交之后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才会真正发送。

方案详解

最大努力通知型方案

最大努力通知方案，以充值场景为例

1. 阻塞式重试

2. 2PC、3PC 传统事务

3. 使用队列，后台异步处理

4. TCC 补偿事务

5. 本地消息表（异步确保）

6. MQ 事务

7. 最大努力通知

TCC 的优点是作用于业务服务层，不依赖某个具体数据库、不与具体框架耦合、资源锁的粒度比较灵活，非常适用于微服务场景下。缺点是每个服务都要实现 3 个 API，对于业务侵入和改动较大，要处理各种失败异常。开发者很难完整处理各种情况，找个成熟的框架可以大大降低成本，比如阿里的 Fescar。

本地消息表的优点是简单、不依赖其他服务的改造、可以很好的配合服务调用和 MQ 一起使用，在大多业务场景下都比较实用。缺点是本地数据库多了消息表，和业务表耦合在一起。文中本地消息表方式的示例，来源于作者写的一个库，有兴趣的同学可以参考下 https://github.com/mushroomsir/tcc

MQ 事务和独立消息服务的优点是抽离出一个公共的服务来解决事务问题，避免每个服务都有消息表和服务耦合在一起，增加服务自身的处理复杂性。缺点是支持事务的 MQ 很少；且每次操作前都先调用 API 添加个消息，会增加整体调用的延迟，在绝大多数正常响应的业务场景下，是一种多余的开销。
来源：cnblogs.com/mushroom/p/13788039.html

分布式事务最好的解决方案就是避免分布式事务。

调用超时

提交失败

第一次校验：
也就是第一个if（singleton==null），这个是为了代码提高代码执行效率，由于单例模式只要一次创建实例即可，所以当创建了一个实例之后，再次调用getInstance方法就不必要进入同步代码块，不用竞争锁。直接返回前面创建的实例即可。

第二次校验：
也就是第二个if（singleton==null），这个校验是防止二次创建实例，假如有一种情况，当singleton还未被创建时，线程t1调用getInstance方法，由于第一次判断singleton==null，此时线程t1准备继续执行，但是由于资源被线程t2抢占了，此时t2页调用getInstance方法，同样的，由于singleton并没有实例化，t2同样可以通过第一个if，然后继续往下执行，同步代码块，第二个if也通过，然后t2线程创建了一个实例singleton。此时t2线程完成任务，资源又回到t1线程，t1此时也进入同步代码块，如果没有这个第二个if，那么，t1就也会创建一个singleton实例，那么，就会出现创建多个实例的情况，但是加上第二个if，就可以完全避免这个多线程导致多次创建实例的问题。

volatile必不可少

比如验证码、IP 黑名单等，这些手段可以有效的防止恶意攻击和爬虫采集；

比如 Tomcat、Nginx 等限流手段，其中 Tomcat 可以设置最大线程数（maxThreads），当并发超过最大线程数会排队等待执行；而 Nginx 提供了两种限流手段：一是控制速率，二是控制并发连接数；

比如我们在服务器端通过限流算法实现限流，此为本模块重点。
服务端限流需要配合限流的算法来执行，而算法相当于执行限流的“大脑”，用于指导限制方案的实现。
有人看到「算法」两个字可能就晕了，觉得很深奥，其实并不是。算法就相当于操作某个事务的具体实现步骤汇总，其实并不难懂，不要被它的表象给吓到哦~
限流的常见算法有以下三种：

Spring Cloud Alibaba | Sentinel

F5

LVS

VS/NAT

VS/TUN

VS/DR

VS/FULLNAT

负载均衡算法

最主流的一种方案就是删除缓存并更新数据库，cache aside。99.9% OK，但还是在极端情况下会出现问题，如何解决？

本地缓存

分布式缓存

适合缓存的场景

不适合缓存的场景

Cache-Aside

Cache-As-SoR

C/C++中，常使用 malloc、new 等 API 动态申请内存。由于申请的内存块大小不一，如果频繁申请、释放会导致大量的内存碎片，并且这些 API 底层依赖系统调用，会有额外的开销。
内存池就是在使用内存钱，先向系统申请一块空间留做备用，使用者需要内存时向内存池申请，用完后还回来。

线程就是程序执行的实体。在服务端开发领域，我们经常会为每个请求分配一个线程去处理，但是线程的创建销毁、调度都会带来额外的开销，线程太多也会导致系统整体性能下降。在这种场景下，我们通常会提前创建若干个线程，通过线程池来进行管理。当请求到来时，只需从线程池选一个线程去执行处理任务即可。
线程池常常和队列一起使用来实现任务调度，主线程收到请求后将创建对应的任务，然后放到队列里，线程池中的工作线程等待队列里的任务。

MySQL 连接池

HTTP 长连接

如果直接发起调用下游服务的方式，如果新增一个下游服务又得改动上游服务，违背依赖倒置原则，即上层服务不应该依赖下层服务。

有些业务涉及到的处理流程非常多，但是很多步骤并不要求实时性。那么我们就可以通过消息队列异步处理。只要核心功能成功，那么就可以返回结果通知用户了。后续的功能，可以通过消息队列发送给下游服务异步处理。大大提高了系统响应速度。

短时间海量请求，一般超过后端服务器的处理能力，那么就可以在接入层将请求放到消息队列里，后端根据自己的处理能力不断从队列里取出请求进行业务处理。

索引提高查找效率，因为索引一般而言是一个排序列表，排序意味着可以基于二分思想进行查找，将查询时间复杂度做到 O(log(N))，快速支持等值查询和范围查询。
二叉搜索树查询效率无疑是最高的，因为平均来说每次比较都能缩小一般的搜索范围，但是一般在数据库索引的实现上却会选择 B+Tree 而不用二叉搜索树。

其他问题

垂直拆分

水平拆分

带来问题

读多写少，读操作首先成为数据库瓶颈，消除读写锁冲突从而提升数据库整体的读写能力。

高性能的服务期应当避免不必要的数据复制，特别是在用户空间和内核空间之间的数据复制。

CAS

在涉及到网络连接、IO 等情况时，将操作批量进行处理能够有效提高系统的传输速率和吞吐量。
在前后端通信中，通过合并一些频繁请求的小资源可以获得更快的加载速度。

例如预先将一些调用外部的名单存到缓存中。

通过预先处理减少了实时链路上的 RPC 调用，既减少了系统的外部依赖，也极大地提高了系统的吞吐量。

预处理在 CPU 和操作系统中也广泛使用。

比如支付宝集五福，“将存入余额，稍后到账”

系统间调用，比如转账，几个动作必须一起成功或者一起都不成功，不能只成功一般，这是保证数据一致性。

COW，Copy On Write，写时复制。

例如拆红包，明明点开的时候显示还有，点击“拆”却显示已经被抢完，就是缓存数据和数据库里的不一致导致的。但这里我们的体验是允许这样的不一致的。

例如支付宝每年分五福就是，转账是异步去弄的。

主要职责

架构师的方方面面

需求的产生和分析

需要做什么

具体实现

测试

数据结构的优化

线程数的设置

缓存的优化

用户体验的优化

举个栗子，读写分离数据库，商品服务写入主库，从读库查询。
商品信息的读写要满足一致性就是要实现如下目标：
1. 商品服务写入主数据库成功，则向从数据库查询新数据也成功；
2. 商品服务写入主数据库失败，则向从数据库查询新数据也失败。

商品信息读取满足可用性就是要实现如下目标：
1. 从数据库接收到数据查询的请求则立即能够响应数据查询结果；
2. 从数据库不允许出现响应超时或响应错误。

商品信息读写满足分区容错性就是要实现如下目标：
1. 主数据库向从数据库同步数据失败不影响读写操作；
2. 其一个节点挂掉不影响另一个节点对外提供服务。

通常 AP 都会保证最终一致性，BASE 理论就是根据 AP 来扩展的。因为对于大多数大型互联网应用的场景，节点众多、部署分散，集群规模越来越到，所以节点故障、网络故障是常态，而且要保证服务可用性达到 N 个 9（99.999...%），并要达到良好的响应性能，用户体验要首先保障。服务不可用是最不可接受的。舍弃数据强一致性，保证最终一致即可。

分类

1. top order by with P: 1040 // 首先按进程负载排序找到 axLoad(pid)

2. top -Hp 进程 PID：1073 // 找到相关负载 线程 PID

3. printf "0x%x\n"线程 PID：0x431 // 将线程 PID 转换为 16 进制，为后面查找 jstack 日志做准备

4. jstack 进程 PID | vim +/十六进制线程 PID - // 例如：jstack 1040 | vim +/0x431 -

改进：
100W台服务器相当于有100W个节点的连通图。那么我们可以在图里生成多颗不同的生成树，在进行数据下发时，同时按照多颗不同的树去传递数据。这样就可以避免某个中间节点宕机，影响到后续的节点。同时这种传递方法实际上是一种依据时间的广度优先遍历，可以避免某条路径过长造成的效率低下。