- 👉《图解网络》 :500 张图 + 15 万字贯穿计算机网络重点知识
- 👉《图解系统》:400 张图 + 16 万字贯穿操作系统重点知识
- 👉《图解MySQL》:重点突击 MySQL 索引、事务、锁、日志等面试高频知识
- 👉《图解Redis》:重点突击 Redis 数据结构、持久化、集群、缓存等面试高频知识
- 👉《Java后端面试题》:涵盖字节、阿里、腾讯、美团、快手、京东、小红书等大厂的面试题
- 👉《吊打面试官》:涵盖消息队列、系统设计、场景题、计算机基础、数据库等面试题
大家好,我是小林。
去年给我印象比较深刻的是得物(得物是一家做年轻人潮牌的电商公司,base 上海)的开奖。
因为开的确实很高,校招毕业年薪 40w 起步,比当时挺多一线大厂的白菜档都开的高,最高档 offer 都到 50w 级别了。
24 届得物校招后端开发岗位薪资
不过,得物工作强度会比较高,所以才开了比较有竞争力的薪资。
今年很多大厂校招薪资相比于去年都涨了不少,比如京东、美团、字节,不少人拿到都是年薪 40-50w 的年薪。
那这次来看看 25 届得物的校招薪资如何?是否相比于去年有一些变化?
我整理了 25 届得物「后端开发岗位」的校招薪资情况如下(根据读者反馈+offershow 的数据):
25 届得物校招后端开发岗位薪资
- 33k x 16 + 1.2k x 12(房补)+ 5w签字费,同学 bg 硕士 985,base 上海
- 32k x 16 + 1.2k x 12(房补)+ 6w签字费,同学 bg 硕士 985,base 上海
- 31k x 16 + 1.2k x 12(房补),同学 bg 硕士 985,base 上海
- 30k x 16 + 1.2k x 12(房补),同学 bg 硕士 985,base 上海 sp offfer:
- 29k x 16 + 1.2k x 12(房补),同学 bg 硕士 985,base 上海
- 28k x 16 + 1.2k x 12(房补),同学 bg 硕士 211,base 上海
- 27k x 16 + 1.2k x 12(房补),同学 bg 硕士 211,base 上海 普通 offer:
- 25k x 16 + 1.2k x 12(房补),同学 bg 硕士 211,base 上海
整体上是相比去年多了,普遍月薪多了 1-2k,得物今年依然很猛啊。
最高的 ssp offer 都有 60w 年包了(算上房补+签字费),即使是白菜 offer 年薪都有 40w+。
很多同学就好奇得物的面试难度如何?
其实都都大厂差不多,围绕八股+项目+算法这三个方面来考察。
这次分享之前同学得物 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 中处理,于是全部请求都直接访问数据库,从而导致数据库的压力骤增,严重的会造成数据库宕机,从而形成一系列连锁反应,造成整个系统崩溃,这就是缓存雪崩的问题。
image.png
- 缓存击穿:如果缓存中的某个热点数据过期了,此时大量的请求访问了该热点数据,就无法从缓存中读取,直接访问数据库,数据库很容易就被高并发的请求冲垮,这就是缓存击穿的问题。
image.png
- 缓存穿透:当用户访问的数据,既不在缓存中,也不在数据库中,导致请求在访问缓存时,发现缓存缺失,再去访问数据库时,发现数据库中也没有要访问的数据,没办法构建缓存数据,来服务后续的请求。那么当有大量这样的请求到来时,数据库的压力骤增,这就是缓存穿透的问题。
image.png
这些缓存问题,有什么解决方案吗?(答上来了)
缓存雪崩解决方案:
- 均匀设置过期时间:如果要给缓存数据设置过期时间,应该避免将大量的数据设置成同一个过期时间。我们可以在对缓存数据设置过期时间时,给这些数据的过期时间加上一个随机数,这样就保证数据不会在同一时间过期。
- 互斥锁:当业务线程在处理用户请求时,如果发现访问的数据不在 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 报文,那么服务端在收到请求后就会建立多个冗余的无效链接,造成不必要的资源浪费。
即两次握手会造成消息滞留情况下,服务端重复接受无用的连接请求 SYN 报文,而造成重复分配资源。
项目
JWT 令牌和传统方式有什么区别?(答上来了)
- 无状态性:JWT是无状态的令牌,不需要在服务器端存储会话信息。相反,JWT令牌中包含了所有必要的信息,如用户身份、权限等。这使得JWT在分布式系统中更加适用,可以方便地进行扩展和跨域访问。
- 安全性:JWT使用密钥对令牌进行签名,确保令牌的完整性和真实性。只有持有正确密钥的服务器才能对令牌进行验证和解析。这种方式比传统的基于会话和Cookie的验证更加安全,有效防止了CSRF(跨站请求伪造)等攻击。
- 跨域支持:JWT令牌可以在不同域之间传递,适用于跨域访问的场景。通过在请求的头部或参数中携带JWT令牌,可以实现无需Cookie的跨域身份验证。
JWT 令牌为什么能解决集群部署,什么是集群部署?( 答上来了)
在传统的基于会话和Cookie的身份验证方式中,会话信息通常存储在服务器的内存或数据库中。但在集群部署中,不同服务器之间没有共享的会话信息,这会导致用户在不同服务器之间切换时需要重新登录,或者需要引入额外的共享机制(如Redis),增加了复杂性和性能开销。
image.png
而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)进行验证。
- 使用数字证书:数字证书是包含公钥和身份信息的数字文件,用于验证签名的合法性。使用数字证书来验证签名可以提高安全性。
- 保护通信渠道:确保数据在传输过程中受到适当的加密和安全措施的保护,以防止中间人攻击。
- 定期更换密钥:定期更换用于签名的密钥,以降低长期存在的密钥被滥用的风险。
最后
反问
我:表现怎么样,还有什么地方需要进一步学习?
面试官:表现不错,问你的也都答上来了,毕竟也是学生,了解的也没那么深,工作中慢慢的了解的就深了,我当年也是什么都不懂,没事儿。
面试感受
都这么烂了,面试官还说不错,面试官人真不错,全程微笑,一起讨论,还主动跟我说我敲字是帮你记录,不是不认真听哈,一开始没答上来,下一个问题告诉我别紧张哈,别受到刚才那个题的影响。
必看图解
- 👉《图解网络》 :500 张图 + 15 万字贯穿计算机网络重点知识
- 👉《图解系统》:400 张图 + 16 万字贯穿操作系统重点知识
- 👉《图解MySQL》:重点突击 MySQL 索引、事务、锁、日志等面试高频知识
- 👉《图解Redis》:重点突击 Redis 数据结构、持久化、集群、缓存等面试高频知识
- 👉《Java后端面试题》:涵盖字节、阿里、腾讯、美团、快手、京东、小红书等大厂的面试题
- 👉《吊打面试官》:涵盖消息队列、系统设计、场景题、计算机基础、数据库等面试题