得物一面，稳扎稳打！
大家好，我是小林。
前几天刚跟大家分享了得物的校招开奖薪资。
很多同学就好奇得物的面试难度如何？其实都都大厂差不多，围绕八股+项目+算法这三个方面来考察。
这次分享之前同学得物Java 后端岗位一面的面试，面试感受不错，有的问题还跟面试官讨论起来。
Java
ArrayList 和 LinkedList 的区别是什么？（答上来了）
数据结构方面：
ArrayList：内部使用动态数组存储数据。因此，它支持随机访问，通过索引访问元素非常快，时间复杂度为O(1)。 LinkedList：内部使用双向链表存储数据。这使得在列表的开头或结尾插入、删除元素非常快，时间复杂度为O(1)。
性能方面：
ArrayList：添加元素时如果需要扩容（即当前数组已满），则需要复制原数组到新的更大的数组，这样的操作时间复杂度为O(n)。而对于非尾部的插入和删除操作，需要移动后面的所有元素，时间复杂度也是O(n)。 LinkedList：对于非首尾的插入和删除操作，需要从头部或尾部遍历到相应的位置，时间复杂度为O(n)。而访问元素（get和set操作）也需要从头部或尾部遍历到相应的位置，时间复杂度为O(n)。
ArrayList 的底层原理是什么？（答上来了）
ArrayList是Java中的动态数组，其底层原理是基于数组实现的。
具体来说，ArrayList内部使用一个Object类型的数组来存储元素。当我们向ArrayList中添加元素时，它会自动调整数组的大小以适应新的元素。当数组的容量不足以容纳新元素时，ArrayList会创建一个更大的数组，并将原数组中的元素复制到新数组中。
这种动态调整数组大小的策略可以确保ArrayList具有可变长度的特性，可以根据需要动态添加或删除元素，而无需手动管理数组的大小。
需要注意的是，由于ArrayList底层使用数组实现，所以在插入或删除元素时，需要将后续的元素进行移动，这可能会影响性能，特别是当ArrayList中的元素数量很大时。因此，在需要频繁进行插入和删除操作的场景下，可能需要考虑使用LinkedList等其他数据结构来替代ArrayList。
ArrayList 是线程安全的吗？（ 答上来了）
ArrayList 不是线程安全的，在多线程环境下，如果多个线程同时对同一个ArrayList实例进行操作（如添加、删除、修改等），会导致数据不一致的问题。
为什么不是线程安全的，具体来说是哪里不安全？（源码层面，没答上来）
在高并发添加数据下，ArrayList会暴露三个问题;
部分值为null（我们并没有add null进去） 索引越界异常 size与我们add的数量不符
为了知道这三种情况是怎么发生的，ArrayList，add 增加元素的代码如下：
public boolean add(E e) {
ensureCapacityInternal(size + 1); // Increments modCount!!
elementData[size++] = e;
return true;
}
ensureCapacityInternal()这个方法的详细代码我们可以暂时不看，它的作用就是判断如果将当前的新元素加到列表后面，列表的elementData数组的大小是否满足，如果size + 1的这个需求长度大于了elementData这个数组的长度，那么就要对这个数组进行扩容。
大体可以分为三步：
判断数组需不需要扩容，如果需要的话，调用grow方法进行扩容； 将数组的size位置设置值（因为数组的下标是从0开始的）； 将当前集合的大小加1
下面我们来分析三种情况都是如何产生的：
部分值为null：当线程1走到了扩容那里发现当前size是9，而数组容量是10，所以不用扩容，这时候cpu让出执行权，线程2也进来了，发现size是9，而数组容量是10，所以不用扩容，这时候线程1继续执行，将数组下标索引为9的位置set值了，还没有来得及执行size++，这时候线程2也来执行了，又把数组下标索引为9的位置set了一遍，这时候两个先后进行size++，导致下标索引10的地方就为null了。 索引越界异常：线程1走到扩容那里发现当前size是9，数组容量是10不用扩容，cpu让出执行权，线程2也发现不用扩容，这时候数组的容量就是10，而线程1 set完之后size++，这时候线程2再进来size就是10，数组的大小只有10，而你要设置下标索引为10的就会越界（数组的下标索引从0开始）； size与我们add的数量不符：这个基本上每次都会发生，这个理解起来也很简单，因为size++本身就不是原子操作，可以分为三步：获取size的值，将size的值加1，将新的size值覆盖掉原来的，线程1和线程2拿到一样的size值加完了同时覆盖，就会导致一次没有加上，所以肯定不会与我们add的数量保持一致的；
ArrayList 和 LinkedList 的应用场景，什么时候该用哪个？（没答上来）
ArrayList适用于需要频繁访问集合元素的场景。它基于数组实现，可以通过索引快速访问元素，因此在按索引查找、遍历和随机访问元素的操作上具有较高的性能。当需要频繁访问和遍历集合元素，并且集合大小不经常改变时，推荐使用ArrayList LinkedList适用于频繁进行插入和删除操作的场景。它基于链表实现，插入和删除元素的操作只需要调整节点的指针，因此在插入和删除操作上具有较高的性能。当需要频繁进行插入和删除操作，或者集合大小经常改变时，可以考虑使用LinkedList。
Redis
缓存雪崩、缓存击穿、缓存穿透是什么？（答上来了）
缓存雪崩：当大量缓存数据在同一时间过期（失效）或者 Redis 故障宕机时，如果此时有大量的用户请求，都无法在 Redis 中处理，于是全部请求都直接访问数据库，从而导致数据库的压力骤增，严重的会造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃，这就是缓存雪崩的问题。
缓存击穿：如果缓存中的某个热点数据过期了，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库很容易就被高并发的请求冲垮，这就是缓存击穿的问题。
缓存穿透：当用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据，没办法构建缓存数据，来服务后续的请求。那么当有大量这样的请求到来时，数据库的压力骤增，这就是缓存穿透的问题。
这些缓存问题，有什么解决方案吗？（答上来了）
缓存雪崩解决方案：
均匀设置过期时间：如果要给缓存数据设置过期时间，应该避免将大量的数据设置成同一个过期时间。我们可以在对缓存数据设置过期时间时，给这些数据的过期时间加上一个随机数，这样就保证数据不会在同一时间过期。 互斥锁：当业务线程在处理用户请求时，如果发现访问的数据不在 Redis 里，就加个互斥锁，保证同一时间内只有一个请求来构建缓存（从数据库读取数据，再将数据更新到 Redis 里），当缓存构建完成后，再释放锁。未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。实现互斥锁的时候，最好设置超时时间，不然第一个请求拿到了锁，然后这个请求发生了某种意外而一直阻塞，一直不释放锁，这时其他请求也一直拿不到锁，整个系统就会出现无响应的现象。 后台更新缓存：业务线程不再负责更新缓存，缓存也不设置有效期，而是让缓存“永久有效”，并将更新缓存的工作交由后台线程定时更新。
缓存击穿解决方案：
互斥锁方案，保证同一时间只有一个业务线程更新缓存，未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。 不给热点数据设置过期时间，由后台异步更新缓存，或者在热点数据准备要过期前，提前通知后台线程更新缓存以及重新设置过期时间；
缓存穿透解决方案：
非法请求的限制：当有大量恶意请求访问不存在的数据的时候，也会发生缓存穿透，因此在 API 入口处我们要判断求请求参数是否合理，请求参数是否含有非法值、请求字段是否存在，如果判断出是恶意请求就直接返回错误，避免进一步访问缓存和数据库。 缓存空值或者默认值：当我们线上业务发现缓存穿透的现象时，可以针对查询的数据，在缓存中设置一个空值或者默认值，这样后续请求就可以从缓存中读取到空值或者默认值，返回给应用，而不会继续查询数据库。 布隆过滤器：我们可以在写入数据库数据时，使用布隆过滤器做个标记，然后在用户请求到来时，业务线程确认缓存失效后，可以通过查询布隆过滤器快速判断数据是否存在，如果不存在，就不用通过查询数据库来判断数据是否存在。即使发生了缓存穿透，大量请求只会查询 Redis 和布隆过滤器，而不会查询数据库，保证了数据库能正常运行，Redis 自身也是支持布隆过滤器的。
网络协议
HTTP1.1怎么对请求做拆包，具体来说怎么拆的？（ 八股没背过这，不知道）
在HTTP/1.1中，请求的拆包是通过"Content-Length"头字段来进行的。该字段指示了请求正文的长度，服务器可以根据该长度来正确接收和解析请求。
具体来说，当客户端发送一个HTTP请求时，会在请求头中添加"Content-Length"字段，该字段的值表示请求正文的字节数。
服务器在接收到请求后，会根据"Content-Length"字段的值来确定请求的长度，并从请求中读取相应数量的字节，直到读取完整个请求内容。
这种基于"Content-Length"字段的拆包机制可以确保服务器正确接收到完整的请求，避免了请求的丢失或截断问题。
讲讲TCP三次握手 （答上来了）
一开始，客户端和服务端都处于 CLOSE 状态。先是服务端主动监听某个端口，处于 LISTEN 状态 客户端会随机初始化序号（client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志位置为 1，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。 服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。 客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位置为 1 ，其次「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端处于 ESTABLISHED 状态。 服务端收到客户端的应答报文后，也进入 ESTABLISHED 状态。
三次握手要实现什么目的？
面试官：同步序列号，保证数据不丢失。我说是建立连接，收发数据，面试官说你这个说的也没问题，另一个角度解释一下。补充：三个方面分析三次握手的原因：
三次握手才可以阻止重复历史连接的初始化（主要原因） 三次握手才可以同步双方的初始序列号 三次握手才可以避免资源浪费
第一个原因：避免历史连接
简单来说，三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。我们考虑一个场景，客户端先发送了 SYN（seq = 90）报文，然后客户端宕机了，而且这个 SYN 报文还被网络阻塞了，服务端并没有收到，接着客户端重启后，又重新向服务端建立连接，发送了 SYN（seq = 100）报文（注意！不是重传 SYN，重传的 SYN 的序列号是一样的）。
看看三次握手是如何阻止历史连接的：
客户端连续发送多次 SYN（都是同一个四元组）建立连接的报文，在网络拥堵情况下：
一个「旧 SYN 报文」比「最新的 SYN」 报文早到达了服务端，那么此时服务端就会回一个 SYN + ACK 报文给客户端，此报文中的确认号是 91（90+1）。 客户端收到后，发现自己期望收到的确认号应该是 100 + 1，而不是 90 + 1，于是就会回 RST 报文。 服务端收到 RST 报文后，就会释放连接。 后续最新的 SYN 抵达了服务端后，客户端与服务端就可以正常的完成三次握手了。
上述中的「旧 SYN 报文」称为历史连接，TCP 使用三次握手建立连接的最主要原因就是防止「历史连接」初始化了连接。
第二个原因：同步双方初始序列号
TCP 协议的通信双方， 都必须维护一个「序列号」， 序列号是可靠传输的一个关键因素，它的作用：
接收方可以去除重复的数据； 接收方可以根据数据包的序列号按序接收； 可以标识发送出去的数据包中， 哪些是已经被对方收到的（通过 ACK 报文中的序列号知道）；
可见，序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了「三次握手」。而两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。
原因三：避免资源浪费
如果只有「两次握手」，当客户端发生的 SYN 报文在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务端不清楚客户端是否收到了自己回复的 ACK 报文，所以服务端每收到一个 SYN 就只能先主动建立一个连接，这会造成什么情况呢？如果客户端发送的 SYN 报文在网络中阻塞了，重复发送多次 SYN 报文，那么服务端在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。
项目
JWT 令牌和传统方式有什么区别？（答上来了）
无状态性：JWT是无状态的令牌，不需要在服务器端存储会话信息。相反，JWT令牌中包含了所有必要的信息，如用户身份、权限等。这使得JWT在分布式系统中更加适用，可以方便地进行扩展和跨域访问。 安全性：JWT使用密钥对令牌进行签名，确保令牌的完整性和真实性。只有持有正确密钥的服务器才能对令牌进行验证和解析。这种方式比传统的基于会话和Cookie的验证更加安全，有效防止了CSRF（跨站请求伪造）等攻击。 跨域支持：JWT令牌可以在不同域之间传递，适用于跨域访问的场景。通过在请求的头部或参数中携带JWT令牌，可以实现无需Cookie的跨域身份验证。
JWT 令牌为什么能解决集群部署，什么是集群部署？（ 答上来了）
在传统的基于会话和Cookie的身份验证方式中，会话信息通常存储在服务器的内存或数据库中。但在集群部署中，不同服务器之间没有共享的会话信息，这会导致用户在不同服务器之间切换时需要重新登录，或者需要引入额外的共享机制（如Redis），增加了复杂性和性能开销。
而JWT令牌通过在令牌中包含所有必要的身份验证和会话信息，使得服务器无需存储会话信息，从而解决了集群部署中的身份验证和会话管理问题。当用户进行登录认证后，服务器将生成一个JWT令牌并返回给客户端。客户端在后续的请求中携带该令牌，服务器可以通过对令牌进行验证和解析来获取用户身份和权限信息，而无需访问共享的会话存储。
由于JWT令牌是自包含的，服务器可以独立地对令牌进行验证，而不需要依赖其他服务器或共享存储。这使得集群中的每个服务器都可以独立处理请求，提高了系统的可伸缩性和容错性。
JWT 令牌都有哪些字段？（ 没答上来，忘了有哪些，没想到会问）
JWT令牌由三个部分组成：头部（Header）、载荷（Payload）和签名（Signature）。其中，头部和载荷均为JSON格式，使用Base64编码进行序列化，而签名部分是对头部、载荷和密钥进行签名后的结果。
JWT 令牌如果泄露了，怎么解决，JWT是怎么做的？
及时失效令牌：当检测到JWT令牌泄露或存在风险时，可以立即将令牌标记为失效状态。服务器在接收到带有失效标记的令牌时，会拒绝对其进行任何操作，从而保护用户的身份和数据安全。 刷新令牌：JWT令牌通常具有一定的有效期，过期后需要重新获取新的令牌。当检测到令牌泄露时，可以主动刷新令牌，即重新生成一个新的令牌，并将旧令牌标记为失效状态。这样，即使泄露的令牌被恶意使用，也会很快失效，减少了被攻击者滥用的风险。 使用黑名单：服务器可以维护一个令牌的黑名单，将泄露的令牌添加到黑名单中。在接收到令牌时，先检查令牌是否在黑名单中，如果在则拒绝操作。这种方法需要服务器维护黑名单的状态，对性能有一定的影响，但可以有效地保护泄露的令牌不被滥用。
网关统一鉴权怎么做的？
答上来了，把流程说一遍就行了（2次算法，时间戳，随机数）
你这个SHA256算法不算加密吧？算签名吧？
完了晕菜了，一直背的用SHA256算法对secretKey加密，没思考过
补充：签名是需要用秘钥和原始数据（或者SHA256 后的数据）一起用加密算法生成的
你说说加密和签名有什么区别？
追问立马就来了，跳进大坑，回答不知道
补充：
加密是为了保护数据，通常对应解密；而签名是将数据和私钥一起用加密算法得到，用于验证数据的来源和完整性，确保数据传输过程中未被修改。 加密要用公钥私钥（对称秘钥），但签名验证可以只用公钥
那如果别人伪造你的签名，你怎么解决？
我说每个用户都有唯一的32位secretKey，没办法伪造
补充：
伪造签名的解决方法：伪造签名是一种安全漏洞，可能导致恶意行为。为了防止伪造签名，可以采取以下措施： 使用安全的密钥管理：确保私钥用于签名的安全存储和管理，以防止未经授权的访问。使用硬件安全模块（HSM）等工具来保护私钥。 使用公开密钥基础设施（PKI）：PKI提供了一种建立信任关系的方式，可以确保公钥的有效性。公钥的合法性可以通过证书颁发机构（CA）进行验证。 使用数字证书：数字证书是包含公钥和身份信息的数字文件，用于验证签名的合法性。使用数字证书来验证签名可以提高安全性。 保护通信渠道：确保数据在传输过程中受到适当的加密和安全措施的保护，以防止中间人攻击。 定期更换密钥：定期更换用于签名的密钥，以降低长期存在的密钥被滥用的风险。
最后
反问
我：表现怎么样，还有什么地方需要进一步学习？
面试官：表现不错，问你的也都答上来了，毕竟也是学生，了解的也没那么深，工作中慢慢的了解的就深了，我当年也是什么都不懂，没事儿。
面试感受
都这么烂了，面试官还说不错，面试官人真不错，全程微笑，一起讨论，还主动跟我说我敲字是帮你记录，不是不认真听哈，一开始没答上来，下一个问题告诉我别紧张哈，别受到刚才那个题的影响
历史好文：