💻 Job

并发与性能优化 1. 大文件上传如何处理？分片上传 相关代码：https://github.com/SwimmingLiu/JavaSceneQuiz100/tree/main/lesson001 1.1 为什么需要分片上传? 大文件在上传的过程中，耗费的时间比较长。如果网络不稳定，很可能导致上传失败，需要重新上传。分片上传，就可以解决这个问题。 分片上传定义：将大文件拆分为不同的文件块，逐块进行上传 1.2 如何实现分片上传？ 1.2.1 如何存储分片信息 分片上传需要记录文件的属性 (md5、大小、名称)、分片数量、文件存储的完整路径 (本地路径)，还需要记录每个分块的上传情况 (分块大小、分块顺序、分块任务id)。可以用 分块上传任务表 和 分块文件表 来记录。 分块任务表 (t_shard_upload) create table if not exists t_shard_upload( id varchar(32) primary key, file_name varchar(256) not null comment '文件名称', part_num int not null comment '分片数量', md5 varchar(128) comment '文件md5值', file_full_path varchar(512) comment '文件完整路径' ) comment = '分片上传任务表'; 分块文件表 (t_shard_upload_part） create table if not exists t_shard_upload_part( id varchar(32) primary key, shard_upload_id varchar(32) not null comment '分片任务id（t_shard_upload.id）', part_order int not null comment '第几个分片，从1开始', file_full_path varchar(512) comment '文件完整路径', UNIQUE KEY `uq_part_order` (`shard_upload_id`,`part_order`) ) comment = '分片文件表，每个分片文件对应一条记录'; 分块文件表和分块上传表是 1 to M 的关系，假如当前文件分为10块。则会出现1个分片上传任务，和10个分片文件记录。 ...

八股题 Java 基础 + 集合 面向对象和面向过程的区别？ 面向对象：将数据和方法封装成对象，作为程序的基本单元来组织代码，包含封装、继承、多态三大特性，方便代码复用和灵活性。 面向过程：以过程做为基本单元来组织代码，过程对应到代码中就是函数，将函数和数据分离，比较关注步骤和流程。其实就是一条路走到底的思想，关注如何设计一系列顺序执行的过程实现。 封装、继承、多态? 封装（Encapsulation）：通过将对象的属性和方法结合为独立单元，并利用访问修饰符（如private）隐藏内部细节，仅通过公共接口（如getter/setter）控制访问，从而提升安全性和可维护性 继承（Inheritance）：允许子类基于父类的属性和方法进行扩展，实现代码复用，Java采用单继承机制（仅支持一个直接父类），但可通过接口实现多重继承的效果 多态（Polymorphism）：同一方法调用因对象实际类型不同而产生不同行为，通常通过父类引用指向子类对象及方法重写实现，依赖运行时动态绑定机制决定具体执行逻辑。（重写和重载） 常见排序算法？时间复杂度？ 直接插入排序：o(n^2) 冒泡排序：o(n^2) 快速排序: o(nlogn) 堆排序：o(nlogn) 归并排序：o(nlogn) 算法 平均时间复杂度 最坏时间复杂度 空间复杂度 稳定性 适用场景 插入排序 O(n²) O(n²) O(1) 稳定 部分有序数据 冒泡排序 O(n²) O(n²) O(1) 稳定 教学示例、小数据 快速排序 O(n log n) O(n²) O(log n) 不稳定 大规模随机数据 归并排序 O(n log n) O(n log n) O(n) 稳定 大数据、外部排序 堆排序 O(n log n) O(n log n) O(1) 不稳定 实时系统、内存受限场景 ArrayList 和 LinkedList 的区别？ ArrayList：底层是动态数组，有扩容机制，内存连续，查询快，增删慢。 LinkedList：底层是双向链表，内存不连续，查询慢，增删快。 【注意】 实际过程中，ArrayList 的增删操作比 LinkedList 快了进百倍。 ...

JVM 全局构架图如下，包含 JVM 的全部内容 1. JVM 的内存区域是如何划分的？ JVM 内存当中，运行时数据的区域包含堆、方法区（元空间）、虚拟机栈、本地方法栈、程序计数器。另外，其他的内存区域属于本地内存，本地内存就包括直接内存，直接内存是非运行时数据区的一部分。 其中，堆和方法区（元空间） 是线程共享的，虚拟机栈、本地方法栈、程序计数器都是线程私有的。 【注意】 JVM 规范对于运行时数据区域的规定是很宽松的。就拿堆来说，堆可以是连续空间，也可以是不连续空间。堆的大小可以固定，也可以再运行时按照需求进行扩展。虚拟机实现者可以使用任何垃圾回收算法管理堆，甚至完全不进行垃圾回收也是可以的。 下面逐一介绍不同部分的功能和作用 首先是线程私有的部分，程序计数器、虚拟机栈、本地方法栈。 【程序计数器】 定义：程序计数器就是记录当前所执行的字节码的行号。字节码解释器通过改变程序计数器的值，来选取下一条需要执行的字节码指令。它的生命周期随着线程的创建而创建，随着线程的结束而死亡。 作用：分支、循环、跳转、异常处理、线程恢复这些功能都需要依赖程序计数器完成。比如线程切换上下文中，从 A线程 先切换到 B线程，然后从 B线程 恢复到 A线程 的过程当中，为了 A线程 能够恢复到正确的执行位置，就需要读取 A线程 程序计数器的值，来确认切换线程前执行的位置在哪里。 为什么是线程私有：因为线程切换的过程当中，每个线程都需要一个程序计数器来记录自己的程序执行位置。 【注意】 程序计数器是唯一一个不会出现 OOM 内存不足的内存区域，因为他就只是存储一个值。 【虚拟机栈】 定义：虚拟机栈按照先进后出的方案存储的是非本地方法的调用对应的栈帧。每一次方法调用的时候会被压入栈中，方法结束的时候会被弹出栈中。栈帧中包含局部变量表、操作次数栈（存储操作数和临时计算结果）、动态链接、方法的返回地址。虚拟机的生命周期随着线程的创建而创建，随着线程的结束而死亡。 作用：存储非本地方法的栈帧，支持方法的调用和返回。当栈深度超过虚拟机允许的最大深度，会抛出 StackOverflowError 栈溢出异常。如果虚拟机栈无法动态扩展或申请到足够的内存，会抛出 OutOfMemoryError 内存不足异常。 栈帧中包含局部变量表、操作次数栈（存储操作数和临时变量）、动态链接、方法的返回地址。其中，局部变量表存放的是所有的局部变量，或者其出对应的地址（数组）。动态链接就是当前类常量池的引用。 局部变量表：存放方法参数传入的形参值，方法内的局部变量、方法的 this 引用。内部结构主要存放了编译期可知的各种数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference 类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针） 操作数栈：主要作为方法调用的中转站使用，用于存放方法执行过程中产生的中间计算结果。另外，计算过程中产生的临时变量也会放在操作数栈中。 动态链接：主要作用是实现在当前方法中调用其他方法。 Class 文件的常量池里面保存有大量的符号引用，比如方法的符号引用。 当一个方法需要调用其他方法，需要将常量池中只想方法的符号引用转换为在内存地址当中的直接引用。动态链接的作用就是把常量池的符号引用转换为内存当中的直接引用。 【本地方法栈】 定义：本地方法栈和虚拟栈的结构是一样的。不同的是，本地方法栈是 JVM 调用 Native 方法的时候才会用到的，虚拟机栈是执行 Java 自身的方法 (也就是字节码) 会用到的。 作用：存储本地方法 (Native) 栈帧，支持方法的调用和返回。 【注意】 在 HotSpot 虚拟机当中，将本地方法栈和虚拟机栈合二为一了。 ...

1. TCP 和 UDP 有什么区别？ TCP 是一种可靠的、面向连接、基于字节流传输的传输协议，能够保证数据的顺序，但是其延迟比较大。一般适用于需要数据完整性和顺序的场景，比如文件传输、邮件、Web 网站。 UDP 是一种不可靠的、无连接、基于数据报传输的传输协议，不能保证数据的顺序，但是延迟比较小。一般适用于需要高性能要求和快速传输数据的应用，比如实时通讯、语音、视频、游戏等。 【注意】TCP 和 UDP 都属于传输层 特性 TCP UDP 连接方式 面向连接 (三次握手) 无连接 可靠性和顺序保证 可靠，保证数据按顺序送达 不可靠，不能保证数据的顺序，而不能保证安全送达 流量控制/拥塞控制 提供流量控制和拥塞控制 没有流量控制和拥塞控制 头部大小 头部较大 (20 ~ 80 字节) 较小 (只有 8 字节) 性能 较低，延迟大 较高，延迟小 是否支持广播 不支持广播 支持广播 数据传输模式 通过字节流传输 通过数据报传输 适用场景 文件传输、Web、邮件等需要可靠性的传输 实时通讯、语音、视频、游戏等高性能要求应用 基于两者的协议 1. HTTP协议：超文本和多媒体内容的协议 2. HTTPS协议：基于HTTP协议上加了一层SSL / TSL 外壳，保证了数据传输的安全性 3. FTP协议： 文件传输协议，用来传文件到服务器的 4. SMTP协议：简单邮件协议，用于发送邮件的协议 (POP3 协议： 负责邮件接受的协议) 1. HTTP 3.0 协议: 基于 UDP 的QUIC 协议 2. DHCP 协议： 动态主机配置协议，动态配置 IP 地址 3. DNS ：域名解析系统，将域名转变为机器刻度的 IP 地址 【ISO 和 TCP/IP 模型】 ...

1. 单例模式有哪几种实现？如何保证线程安全？ 首先，单例模式和工厂模式都是一种设计模式。单例模式当中，一个类只允许创建一个对象(或者说实例)， 那这个类就是单例类。单例类是不可以被继承的，也没有了多态的特性。 【单例类的实现方式】 常规单例模式有五种写法，但是编写代码的过程当中，要注意以下几点： 构造器需要私有化 暴露一个公共获取单例对象的接口 （obj.getInstance()） 是否支持懒加载 延迟加载 是否线程安全 五种写法为： 饿汉式： 类加载的时候，就一起把 instance 静态实例创建好了，所以创建的过程市线程安全的。 饿汉式的单例模式虽然不支持懒加载，有点浪费资源。但其实不会占用太多资源，并且如果一个实例初始化的过程比较复杂，就应该放在启动的时候来处理，避免运行时卡顿或发生问题， 满足fail-fast 失败快速解决的设计原则 public class EagerSingleton { private static Singleton instance = new Singleton(); private Singleton (){} public static Singleton getInstance() { return instance; } } 懒汉式：相较于饿汉式的方式，修改成延迟加载的模式。注意getInstance()方法没有上锁的话，在大量线程并发请求的时候，可能创建多个实例。 public class Singleton { private static Singleton instance; private Singleton (){} public synchronized static Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } } 双重检查锁：饿汉式锁不支持延迟加载，然后懒汉式锁的粒度比较大，不支持高并发。双重检查锁可以实现既延迟加载，又支持高并发。其实就是在判断了没有实例之后，再进行上锁，创建实例。 但是实例必须用volatile 修饰，不然new 操作创建对象时，容易出现重排序的问题。 ...

1. 什么是 Java 内存模型（JMM）？ JMM 是 Java内存模型 ， 它是Java虚拟机 JVM 定义的一种规范，用于描述多线程程序中的变量，像实例字段、静态字段和数组元素，他们如何在内存中存储和传递的规则。也就是规定线程啥时候从住内存里面读数据，啥时候把数据写回到住内存。JMM 的核心目标是确保多线程环境下的可见性、有序性和原子性, 避免硬件和编译器优化带来的不一致问题。 JMM 当中包含主内存 (所有线程共享) 和 工作内存 （每个线程私有）两种内存。 主内存：主内存是Java堆内存的一部分，是线程共享的区域，存储全局变量，比如静态变量、实例字段、数组元素等等。线程不能直接操作主内存，必须通过工作内存间接访问。 工作内存：每个线程私有的本地内存，缓存主内存的变量副本。线程对变量的读写操作均在工作内存种进行，修改后的结果需要同步会主内存。线程是通过内存屏障 ( volatile 关键字) 或者 同步操作 ( synchronized ) 实现主内存和工作内存的数据一致性的。 【可见性、有序性、原子性定义】 可见性：确保一个线程对共享变量的修改，能够及时被另外一个线程看到。 volatile就是用来保证可见性的，强制线程每次读写的时候，直接从主内存当中获取最新值。 有序性：指线程执行操作的顺序。JMM允许某些指令重排序之后再提高性能，但会保证线程内的操作顺序不会被破坏。通过happens-before (线程A发生在线程B之前)的关系来保证跨线程的有序性。 原子性：操作不可分割，线程不会在执行的过程当中被打断。例如, synchronize 关键字能确保方法或代码块的原子性 【JMM作用】 因为不同的操作系统都有一套独立的内存模型，但是Java为了满足跨平台的特性，它需要定义一套内存模型屏蔽个操作系统之间的差异。我们可以利用JMM当中定义好的从Java源码到CPU指令的执行规范，也就是使用synchronized 、volatile 等关键字，还有happens-before原则，就可以写出并发安全的代码了。 比如说，线程A和线程B同时操作 变量-1，假如最开始变量-1 是 0 首先，线程A和线程B都读取了变量-1 然后，线程B对取到的变量-1自增为1，并写回主内存 此时，线程A对读取到的变量-1也自增1，并写回主内存。这就会导致线程B的操作失效了，出现并发安全问题。 如果有JMM，我们就可以在线程A要修改数据之前,让它采用CAS乐观锁的方式进行修改。再次去读主内存当中的值，然后修改之后，再判断一下主内存的值是否发生变化。如果没有发生变化，就写回主内存。如果发生变化，就要进行自旋。 【注意】 工作内存是每个线程独立的内存空间，其他线程都是看不到的。主内存是Java堆内存的一部分，所有的实例变量、静态变量和数组元素都存储在主内存当中。 【内存间交互操作类型 (8种原子操作)】 lock 上锁：把一个变量表示为一条线程独占的状态 unlock 解锁： 把一个变量从独占状态中释放出来，释放后的变量才能被其他线程锁定 read 读取： 从主内存当中读取一个变量到工作内存中 load 载入：把read操作从主内存中得到的变量值放入工作内存的变量副本当中 use 使用：把工作内存当中的一个变量值传递给执行引擎 assign 赋值：把一个从执行引擎接收到的值赋给工作内存中的变量 store 存储：把工作内存中的一个变量的值传送给主内存中 write 写入：把store操作从工作内存中得到的变量值放入主内存的变量中 【volatile 特殊规则】 ...

1. 说说你知道的几种 I/O 模型 【常见的五大I/O模型】 常见的五大I/O模式分别为: 同步阻塞I/O (Blocking I/O) BIO、非阻塞I/O (Non-blocking I/O) NIO、I/O多路复用、信号量驱动I/O、异步I/O AIO 我们假如要烧水喝，看不同模型是怎么烧的水喝 I/O 模型 特性 烧水案例 同步阻塞I/O BIO 数据从网卡到内核，再从内核到用户空间，都是阻塞操作。 自己动手烧水，一直盯着，等水烧开了，倒在杯子里喝。 非阻塞I/O NIO 数据从网卡到内核不阻塞，read不到数据直接返回，但是从内核到用户空间会阻塞 (用户轮询read) 自己动手烧水，隔两分钟看一下，水烧开没有。等水烧开了，倒在杯子里喝。 I/O多路复用 只有一个线程查看多个连接是否有数据准备就绪 (看从网卡能不能read到数据到内核) 找专门烧水的领居帮忙，他把水烧好了之后，会喊你来拿。但是你要自己倒在杯子里喝。 信号驱动I/O 数据从网卡到内核之后会自动通知用户程序，然后让他read读取数据 去烧水房烧水，全自动的，有个通知灯。水烧完了之后会按你家的门铃，但是有客人来了，也会按门铃 异步I/O AIO 全程不阻塞，拷贝到用户空间之后直接回调。 和多路复用类似，但是烧完水之后不用自己倒水，他帮你倒好了，还吹凉了，你过来喝就行。 【为什么会产生各种I/O】 下图是两个不同主机上，应用程序传递数据的过程，借助该过程来理解 I/O 是如何产生的 DMA（直接内存访问）是一种不经过CPU直接在网络适配器（网卡）和主机内存之间进行数据传输的机制，用于提升数据传输效率。 【同步阻塞 I/O BIO】 同步阻塞I/O BIO 的工作机制：应用程序被阻塞，直到数据复制到应用进程的缓冲区才返回。阻塞并意味着整个操作系统都被阻塞。其他程序还可以执行，不消耗CPU事件。同步阻塞 I/O BIO 中，应用程序发起 read 调用来读取数据之后，一直被阻塞，直到内核把数据copy到用户空间。该方案适合客户端连接数量不高的情况。下图的read 和 recvfrom 函数是一个意思。 【非阻塞式 I/O NIO】 非阻塞式 I/O NIO 的工作机制：应用程序执行read 系统调用之后，内核返回一个错误码。应用程序可以继续执行，但是需要不断的轮询 read 来获取 I/O是否完成，这种方式称之为 轮询 polling 。等到数据准备就绪，从内核空间copy到用户空间的时候，进程才被阻塞，直到内核copy完成。该方案比较低效，会不停的消耗CPU资源。 ...

个人简历详情查看 -> 个人简历页 1. 异步秒杀机制的异步是如何实现的? 【正常秒杀的顺序】 查询优惠券 -> 判断秒杀库存 -> 查询订单 -> 校验是否一人一单 -> 扣减库存 -> 创建订单 【异步秒杀】 为了实现用户异步下单，其实就是把是否能够下单的判断逻辑和下单的操作拆分开。 采用Redis来判断是否有足够的库存和校验一人一单 如果满足条件，把用户、订单id、商品id保存到阻塞队列，直接给用户返回秒杀成功。 如果不满足条件，直接返回秒杀失败。 后台线程会去执行queue里边的消息 这样就可以实现异步的秒杀下单了，那么如果实现判断秒杀库存和校验一人一单呢？ 【秒杀库存 + 一人一单】 用户下单之后，判断redis当中的库存key的value是否大于0 value > 0 -> 第2步 value <= 0 -> 直接返回库存不足 （返回1） 如果库存充足，判断redis当中的秒杀商品key的 set 集合是否已包含userid 包含userid， 说明用户已经下单了，直接返回当前用户已下单 (返回2) 不包含 userid -> 第3步 如果用户没有下单，将用户的 userid 存入 set 里面 (返回0) 【注意】 整个操作是原子性的，这样就确保了不会出现超卖现象和一人多单现象 -- 1.参数列表 -- 1.1.秒杀商品id local voucherId = ARGV[1] -- 1.2.用户id local userId = ARGV[2] -- 1.3.订单id local orderId = ARGV[3] -- 2.数据key -- 2.1.库存key local stockKey = 'seckill:stock:' .. voucherId -- 2.2.秒杀商品订单key local orderKey = 'seckill:order:' .. voucherId -- 3.脚本业务 -- 3.1.判断库存是否充足 get stockKey if(tonumber(redis.call('get', stockKey)) <= 0) then -- 3.2.库存不足，返回1 return 1 end -- 3.2.判断用户是否下单 SISMEMBER orderKey userId if(redis.call('sismember', orderKey, userId) == 1) then -- 3.3.存在，说明是重复下单，返回2 return 2 end return 0 【阻塞队列实现下单】 ...

1. Redis主从复制的原理 【主从复制的原理】 同步：从节点向主节点发送psync命令进行同步，从节点保存主节点返回的 runid 和 offset 全量复制：如果是第一次连接或者连接失败且repl_backlog_buffer 缓存区不包含slave_repl_offset， 则生成主节点的数据快照(RDB文件)发给从节点 增量复制：全量复制完毕后，主从节点之间会保持长连接。如果连接没有断开或者slave_repl_offset仍然在repl_backlog_buffer中，则将后续的写操作传递给从节点，让数据保持一致。 【全量复制细节】 全量复制的过程是基于TCP长连接的，主要流程如下 从节点发送psync ? -1表示需要建立连接进行同步，主节点返回主节点ID runid 和 复制进度offset (第一次同步用 -1 表示)。从节点接受之后，保存主节点的信息。 主节点执行bgsave命令生成数据快照RDB文件，然后将RDB文件发送给从节点。从节点接受文件后，清除现有的所有数据，然后加载RDB文件 如果在制作数据快照RDB文件的过程当中，主节点接收到了新的写操作，主节点会将其记录在repl buffer 里面。然后将repl buffer当中的写操作发给从节点，让其数据保持一致。 【增量复制细节】 如果主从节点意外断开连接，为了保持数据的一致性，必须重新同步数据。如果使用全量复制来保持一致性的话，开销太大，所以采用增量复制。 增量复制的具体流程如下： 连接恢复后，从节点会发送psync {runid} {offset}， 其中主节点ID runid 和 复制进度offset用于标识是哪一个服务器主机和复制进度。 主节点收到psync 命令之后，会用conitnue响应告知从节点，采用增量复制同步数据 最后，主节点根据offset查找对应的进度，将断线期间未同步的写命令，发送给从节点。同时，主节点将所有的写命令写入repl_backlog_buffer， 用于后续判断是采用增量复制还是全量复制。 【注意】从节点 psync 携带的 offset 为 slave_repl_offset。如果 repl_backlog_buffer包含slave_repl_offset 对应的部分，则采用增量复制，否则采用全量复制。repl_backlog_buffer的默认缓冲区大小为1M 【为什么要主从复制】 备份数据：主从复制实现了数据的热备份，是持久化之外的数据冗余方式 故障恢复：当主节点宕机之后，可以采用从节点提供服务。 负载均衡: 主从复制实现了读写分离，只有主节点支持读写操作，从节点只有读操作。在读多写少的场景下，可以提高Redis服务器的并发量。 2. Redis集群的实现原理是什么? 【Redis集群基本知识】 定义: Redis集群由多个实例组成，每个实例存储部分数据 (每个实例之间的数据不重复) 。 【注】集群和主从节点不是一个东西，集群的某一个实例当中可能包含一个主节点 + 多个从节点 为什么用 问题 解决方案 容量不足 数据分片，将数据分散不存到不同的主节点 高并发写入 数据分片，将写入请求分摊到多个主节点 主机宕机问题 自动切换主从节点，避免影响服务， 不需要手动修改客户端配置 节点通信协议：Redis集群采用Gossip协议, 支持分布式信息传播、延迟低、效率高。采用去中心化思想，任意实例(主节点)都可以作为请求入口，节点间相互通信。 分片原理： 采用哈希槽(Hash Slot)机制来分配数据，整个空间可以划分为16384 (16 * 1024)个槽。 每个Redis负责一定范围的哈希槽,数据的key经过哈希函数计算之后对16384取余可定位到对应的节点。 ...

1. 说说 Java 中 HashMap 的原理？ 【HashMap定义】 结构：数组 + 链表 + 红黑树 (JDK 1.8 之后) 默认值：初始容量为16 (数组长度)，负载因子为 0.75。当存储的元素为 16 * 0.75 = 12个时，会触发Resize() 扩容操作，容量 x 2 并重新分配位置。但是扩容是有一定开销的，频繁扩容会影响性能。另外，TREEIFY_THRESHOLD 转换为红黑树的默认链表长度阈值为 8, UNTREEIFY_THRESHOLD 从红黑树转换为链表的阈值为 6。 两个阈值采用不同值的原因是防止刚转换为红黑树，又变成链表，反复横跳，消耗资源。 数组下标位置计算方法：首先使用key的hashCode()方法计算下标位置，然后通过 indexFor() (JDK 1.7 以前) 计算下标值。 JDK 1.7后，为了提高计算效率采用 (len - 1) & hash 来确定下标值。 【注】数组的长度len 是2的幂次方时，(len - 1) & hash 等价于 hash % len。 这也是为什么数组长度必须是2的幂次方。 【HashMap线程不安全】 为了保证HashMap的读写效率高，它的操作是非同步的，也就是说读写操作没有锁保护。所以多线程场景下是线程不安全的。 【HashMap不同版本区别】 JDK 1.7: 数组 + 链表，链表部分采用头插法，多线程会导致出现环形链表。扩容会计算每个元素hash值，并分配到新的位置，开销大。 JDK 1.8：数组 + 链表 + 红黑树，采用高低位置来分配位置，即判断(e.hash & oldCap) == 0， 减少了计算hash的次数 【HashMap的PUT方法】 ...