字节跳动电商后端面经

流式读取必要性？

1. 流式读取可以解决大文件或处理大数据量时的内存溢出问题，因为流式读取无需将文件一次性加载到内存中，仅读取当前处理片段，适配内存有限的场景，边读边处理数据还可以降低等待时间。能够避免一次性加载大数据而导致GC频繁、系统卡顿，提升程序的稳定性。

文件上传流程

1. 我在实现文件上传功能时，首先在前端对大文件分片、设置请求头并通过FormData进行上传；后端接收时检验文件的类型、大小等属性，随后将文件存储到数据库中，如果涉及分片则合并后转存，需要文件回调则返回文件的URL/MD5，再更新数据库的文件记录。

介绍一下Java的强/软/弱/虚引用?

1. 在垃圾回收的过程中根据对象被哪些引用类型指向判断对象是否可以被回收，从而对对象的生命周期进行更精细地控制与监控。
2. 强引用不会被垃圾回收器回收，新创建的对象会被强引用指向；软引用在系统内存不足时会被垃圾回收器回收，用于描述有用但是非必需的对象；弱引用在每次垃圾回收时都会被回收，可以实现对象缓存；虚引用在对象被回收之前会被放入引用队列中，用于跟踪对象被垃圾回收的时机，由程序员进行处理。

concurrenthashmap的底层原理是什么？

1. JDK1.7中，ConcurrentHashMap使用了数组 + 链表的数据结构，数组分为大数组Segement和小数组HashEntry，采用分段锁技术实现线程安全，即对每个Segment独立加锁，小数组HashEntry用于存储键值对数据。读操作无锁，使用volatile保证可见性，根据HashEntry的volatile字段保证读操作能获取最新值。写操作对目标加锁，完成后释放，同一Segment写操作互斥。
2. JDK1.8中，ConcurrentHashMap使用的是数组 + 链表 + 红黑树的结构。并发控制体现在操作时会判断数组节点是否为空，如果为空则使用CAS无锁插入，如果不为空则使用Synchronized锁定当前链表/红黑树节点后进行操作。可以缩小锁的粒度，让发生冲突和加锁的频率降低，实现线程安全的同时提高并发操作性能。

volatile原理是什么？

1. volatile能够保证变量的可见性，禁止指令重排，但是不能保证原子性。
2. 当一个变量被volatile修饰时，对这个变量进行写操作后，JMM会立即把工作内存中的最新变量强制刷新到主内存中，并通知其他线程该变量已被修改，同时写操作会使其他线程中的缓存失效，使用变量时只能到主存中读取。
3. volatile会在读写操作指令的前后插入内存屏障，指令重排序是不会把后面的指令重排序到内存屏障中，一次可以保证指令的执行顺序。

b树b+树区别是什么？

1. B树在叶子节点和非叶子节点都存储数据，每个节点存储的索引值少，树的深度大，且叶子节点之间没有关联，进行范围查询时需要进行回溯，效率比较低。
2. B+树只在叶子节点存储数据，在非叶子节点存储索引，且叶子节点之间使用双向链表连接，支持范围查询，并且左右子树高度差不超过1，能够保证查询效率稳定。所以MySQL索引的核心数据结构是B+树，是适配磁盘存储的多路平衡查找树。

索引失效场景有哪些？

1. 对索引使用模糊查询以%开头时，进行左/左右模糊匹配-，会造成索引失效。因为B+树索引是按照前缀顺序存储的，无法通过前缀匹配定位索引位置
2. 对索引字段使用函数或者对索引进行表达式计算会导致索引失效，索引保存的是字段的原始值，而不是计算后的值；在MySQL8.0后可以给函数计算后的值建立一个索引，可以扫描索引查询数据。
3. 对索引进行隐式类型转换会使索引失效，如果索引字段是字符串类型，输入参数是整型时索引会失效。因为MySQL在遇到字符串和数字比较的时候会自动把字符串转换成数字，相当于给索引使用了类型转换函数，破坏了索引的原始值而导致失效。
4. 联合索引不遵循最左匹配原则会导致部分索引失效，因为联合索引数据会按照索引第一列排序，第一列数据相同才会按照第二列排序，必须从最左侧开始匹配，否则无法定位。
5. WHERE子句如果有OR，OR的其中一侧没有索引就会导致索引失效，有条件不是索引列就会进行全表扫描。
6. 使用!=/<>/NOT IN或NOT EXISTS可能导致索引失效，因为否定操作需要匹配大部分数据，MySQL认为全表扫描比走索引更高效，会放弃索引。

redolog和undolog了解吗？

1. RedoLog是重做日志，会记录数据页的物理修改。当事务提交时会先顺序写入RedoLog中，日志落盘则判定提交成功，这样如果数据库宕机，重启后也会通过重做日志重做所有已提交的事务，实现数据的永久保存。在MySQL中和内存刷盘机制实现持久性，即执行时写入，提交时刷盘，保证强持久化。
2. UndoLog是回滚日志，记录的是数据修改前的快照。在事务执行的每一步会记录反向日志，事务回滚时可以通过UndoLog撤销已经执行的修改，回滚到日志开始前的状态。常用于实现MVCC（多版本并发控制），提供读已提交/可重复读隔离级别。

redis缓存穿透、击穿、雪崩以及解决方法？

1. 缓存穿透：用户访问的数据不在缓存和数据库中，大量请求进入数据库且无法通过缓存恢复数据解决，数据库压力过大。可以通过对非法请求的限制、缓存空值或默认值以及使用布隆过滤器快速判断数据是否存在来解决，防止大量数据查询数据库。
2. 缓存击穿：缓存中的某个热点数据过期，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接缓存在数据库，数据库被高并发的请求冲垮。可以使用互斥锁方案或者不给热点数据设置过期时间，由后台线程异步更新缓存。
3. 缓存雪崩：大量缓存数据集中在一段时间内过期失效或者Redis故障宕机时，Redis无法处理请求，全部请求访问数据库，数据库压力过大会引起连锁反应，整个系统崩溃。针对大量数据同时过期，通过给数据过期时间加随机数、给访问数据库的请求添加互斥锁或者使用后台线程定时更新缓存解决。针对Redis故障宕机，通过服务熔断或请求限流机制，也可以选择构建Redis缓存高可靠集群。

图怎么判断有环？讲一下思路

1. 对于有向图，可以使用拓扑排序，计算所有节点的入度，入度为0的节点入队，出队时删除其出边，同时更新邻接节点入度，如果最终遍历节点数不等于总节点数，则说明有环；还可以使用DFS判断，标记节点为未访问/访问中/已访问三个状态，遍历节点时标记为访问中，如果递归到访问中的节点则说明有环。
2. 对于无向图可以使用DFS，遍历每个节点时记录父节点，如果邻接节点已经访问且不是父节点，则说明有环。