详情

图解学习网站：欧洲杯体育

全球好，我是小林。

腾讯云智属于腾讯的子公司，端庄的业务大部分是腾讯云关联的，有在腾讯csig的一又友跟我聊过，他和腾讯云智的共事亦然频频打交说念的。

诚然腾讯云智被大广大东说念主称为大厂内包，关联词大厂内包职责阅历的求职影响其实莫得像外包公司那么大，反而如故挺平时的阅历，致使可能比一些中微型公司更好一些。

为什么这样说呢？因为干的活等于大厂的形态，职责的挑战性和成长性这些会比中微型公司更强。

腾讯云智公司主要在二线城市，总部是西安，然后长沙、武汉都有办公场合，把柄本年腾讯云智校招薪资开奖信息来看的话，设备岗亭的普通档 offer 举座年包在 22～24w，sp offer 年包在 26w～27w，在二线城市的话，还算可以的。

之前有考研营同学拿到腾讯云智的实习offer，拿到了之后，就遴荐径直去了，再也不想口试了。

因为在拿到腾讯云智offer之前，他口试的历程相称迤逦，他在最首先也有拿到许多中大厂公司的口试契机，比如腾讯、字节等等，不外由于准备的比较仓促，再加上非科班，诚然八股都背的差未几了，关联词如故一个个点，莫得把常识串起来，而且口试的时候，也没什么我方想考的历程，遭逢没背过的，就嗅觉脑子顿住了。

是以刚首先出去找实习这几个月，基本都挂了，挂了不可怕，可怕不去编削和反想，经过前边的失败翻盘和编削之后，才顺利斩获了腾讯云智offer。

腾讯云智实习诚然不如一线大厂，关联词要是一线大厂契机比较少，亦然可以尝试冲大厂子公司，旧年也有同学跟我反馈，他实习去了腾讯云智，关联词秋招如故拿到了大厂offer，他以为腾讯云智的实习，学到了蛮多的公司，大厂口试官都挺感兴趣的，唯有引起口试官感兴趣去发问和你交流，那么这段阅历等于加分的。

那此次咱们就来望望腾讯云智口试难度若何？

举座我嗅觉口试作风挺雷同腾讯，心爱问野神思基础多一些，然后每个常用的后端组件拷打几个问题，亦然不异有手撕算法模范，是以想冲腾讯云智的同学，算法如故得多刷刷。

腾讯云智（一面）ConcurrentHashMap若何保证线程安全的？

JDK 1.7 ConcurrentHashMap

JDK 1.7 ConcurrentHashMap

在 JDK 1.7 中它使用的是数组加链表的体式兑现的，而数组又分为：大数组 Segment 和一丝组 HashEntry。 Segment 是一种可重入锁（ReentrantLock），在 ConcurrentHashMap 里演出锁的变装；HashEntry 则用于存储键值对数据。一个 ConcurrentHashMap 里包含一个 Segment 数组，一个 Segment 里包含一个 HashEntry 数组，每个 HashEntry 是一个链表结构的元素。

JDK 1.7 ConcurrentHashMap 分段锁期间将数据分红一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁探问其中一个段数据的时候，其他段的数据也能被其他线程探问，大致兑现的确的并发探问。

JDK 1.8 ConcurrentHashMap

JDK 1.8 ConcurrentHashMap

在 JDK 1.7 中，ConcurrentHashMap 诚然是线程安全的，但因为它的底层兑现是数组 + 链表的体式，是以在数据比较多的情况下探问是很慢的，因为要遍历系数这个词链表，而 JDK 1.8 则使用了数组 + 链表/红黑树的方式优化了 ConcurrentHashMap 的兑现，具体兑现结构如下：

JDK 1.8 ConcurrentHashMap JDK 1.8 ConcurrentHashMap 主要通过 volatile + CAS 或者 synchronized 来兑现的线程安全的。添加元素时领先会判断容器是否为空：

要是为空则使用 volatile 加 CAS 来运调治

要是容器不为空，则把柄存储的元素野心该位置是否为空。

要是把柄存储的元素野心死亡为空，则附近 CAS 配置该节点；

要是把柄存储的元素野心死亡不为空，则使用 synchronized ，然后，遍历桶中的数据，并替换或新增节点到桶中，终末再判断是否需要转为红黑树，这样就能保证并发探问时的线程安全了。

要是为空则使用 volatile 加 CAS 来运调治

要是容器不为空，则把柄存储的元素野心该位置是否为空。

要是把柄存储的元素野心死亡为空，则附近 CAS 配置该节点；

要是把柄存储的元素野心死亡不为空，则使用 synchronized ，然后，遍历桶中的数据，并替换或新增节点到桶中，终末再判断是否需要转为红黑树，这样就能保证并发探问时的线程安全了。

要是把柄存储的元素野心死亡为空，则附近 CAS 配置该节点；

要是把柄存储的元素野心死亡不为空，则使用 synchronized ，然后，遍历桶中的数据，并替换或新增节点到桶中，终末再判断是否需要转为红黑树，这样就能保证并发探问时的线程安全了。

要是把上头的试验用一句话归纳的话，就绝顶于是ConcurrentHashMap通过党羽结点加锁来保证线程安全的，锁的粒度比拟 Segment 来说更小了，发生碎裂和加锁的频率裁减了，并发操作的性能就提高了。

而且 JDK 1.8 使用的是红黑树优化了之前的固定链表，那么当数据量比较大的时候，查询性能也得到了很大的进步，从之前的 O(n) 优化到了 O(logn) 的时辰复杂度。

Redis可以惩处什么问题？

Redis 是一种基于内存的数据库，对数据的读写操作都是在内存中完成，因此读写速率相称快，常用于缓存，音问队伍、分散式锁等场景。

缓存: Redis最常见的用途等于看成缓存系统。通过将热点数据存储在内存中，可以极地面提高探问速率，减弱数据库负载，这关于需要快速反馈时辰的应用模范相称紧迫。

排名榜: Redis的有序聚合结构相称合适用于兑现排名榜和排名系统，可以浅陋地进行数据排序和排名。

分散式锁: Redis的特点可以用来兑现分散式锁，确保多个程度或做事之间的数据操作的原子性和一致性。

计数器由于Redis的原子操作和高性能，它相称合适用于兑现计数器和统计数据的存储，如网站探问量统计、点赞数统计等。

缓存: Redis最常见的用途等于看成缓存系统。通过将热点数据存储在内存中，可以极地面提高探问速率，减弱数据库负载，这关于需要快速反馈时辰的应用模范相称紧迫。

排名榜: Redis的有序聚合结构相称合适用于兑现排名榜和排名系统，可以浅陋地进行数据排序和排名。

分散式锁: Redis的特点可以用来兑现分散式锁，确保多个程度或做事之间的数据操作的原子性和一致性。

计数器由于Redis的原子操作和高性能，它相称合适用于兑现计数器和统计数据的存储，如网站探问量统计、点赞数统计等。

虚构内存是操作系统提供给每个运行中模范的一种地址空间，每个模范在运行时认为我方领有的内存空间等于虚构内存，其大小可以远广大于物理内存的大小。虚构内存通过将模范的地址空间永别红若干个固定大小的页或段，并将这些页或者段映射到物理内存中的不同位置，从而使得模范在运行时可以更高效地附近物理内存。

要是操作系统不撑持虚构内存，模范的运即将受到物理内存的径直落拓，可能激发以下中枢问题：

物理内存不及：当代模范（如大型游戏、虚构机、数据库）粗造需要数 GB 的内存。若物理内存较小（如早期野神思的 MB 级内存），模范无法加载一起数据和代码，导致无法启动或频繁崩溃。

内存碎屑化：物理内存被多个模范分割为不连气儿的块，即使总容量饱胀，也可能因无法找到连气儿的大内存块而无法加载新模范。举例，物理内存剩余 1GB 但被拆分为多个小碎屑，此时需要 800MB 连气儿内存的模范将无法运行。

地址越界探问：莫得虚构内存的地址映射机制，模范径直操作物理内存，可能误读或修改其他模范的内存数据，导致模范崩溃或数据线路。举例，一个模范的指针特殊可能掩盖系统内核或其他模范的关节数据。

坏心报复风险：模范可径直探问恣意物理内存地址，坏心软件易通过内存批改碎裂系统或窃取信息。

物理内存不及：当代模范（如大型游戏、虚构机、数据库）粗造需要数 GB 的内存。若物理内存较小（如早期野神思的 MB 级内存），模范无法加载一起数据和代码，导致无法启动或频繁崩溃。

内存碎屑化：物理内存被多个模范分割为不连气儿的块，即使总容量饱胀，也可能因无法找到连气儿的大内存块而无法加载新模范。举例，物理内存剩余 1GB 但被拆分为多个小碎屑，此时需要 800MB 连气儿内存的模范将无法运行。

地址越界探问：莫得虚构内存的地址映射机制，模范径直操作物理内存，可能误读或修改其他模范的内存数据，导致模范崩溃或数据线路。举例，一个模范的指针特殊可能掩盖系统内核或其他模范的关节数据。

坏心报复风险：模范可径直探问恣意物理内存地址，坏心软件易通过内存批改碎裂系统或窃取信息。

多程度和多线程的区别：

多程度需通过 IPC（程度间通讯）机制（如管说念、Socket、分享内存）传递数据，通讯复杂度高但安全性强。多线程可径直探问分享变量，通讯约略但需处理线程安全（如加锁、原子操作），易激发竞态条目。

多程度的程度间都备结巴，一个程度崩溃不影响其他程度，而多线程的线程间分享资源，一个线程崩溃可能导致系数这个词程度崩溃。

多程度的程度创建 / 切换支拨大（需分拨内存、复制页表等），多线程的线程创建 / 切换支拨小（仅需保存寄存器情景）。

多程度需通过 IPC（程度间通讯）机制（如管说念、Socket、分享内存）传递数据，通讯复杂度高但安全性强。多线程可径直探问分享变量，通讯约略但需处理线程安全（如加锁、原子操作），易激发竞态条目。

多程度的程度间都备结巴，一个程度崩溃不影响其他程度，而多线程的线程间分享资源，一个线程崩溃可能导致系数这个词程度崩溃。

多程度的程度创建 / 切换支拨大（需分拨内存、复制页表等），多线程的线程创建 / 切换支拨小（仅需保存寄存器情景）。

若何遴荐？

当任务 IO 密集、需频繁分享数据，或追求轻量级并发时，可以优先遴荐多线程。

当任务 CPU 密集、需强结巴性，或跨平台 / 言语集成时，可以优先遴荐多程度。

当任务 IO 密集、需频繁分享数据，或追求轻量级并发时，可以优先遴荐多线程。

当任务 CPU 密集、需强结巴性，或跨平台 / 言语集成时，可以优先遴荐多程度。

维度POSTPUT 幂等性非幂等：屡次相通苦求可能产生不同死亡幂等：屡次相通苦求死亡相通（掩盖或创建） 资源操作粗造用于创建新资源（如注册用户）粗造用于更新已有资源（如修改用户信息） 资源符号客户端不指定资源 ID，由做事器生成（如/users）客户端需指定资源 ID（如/users/123） 数据处理提交的数据看成苦求的 “从属品”（如表单）提交的数据是资源的完竣流露（掩盖原内容）

Post和Get的区别是什么？

把柄 RFC 表率，GET 的语义是从做事器赢得指定的资源，这个资源可以是静态的文本、页面、图片视频等。GET 苦求的参数位置一般是写在 URL 中，URL 章程只可撑持 ASCII，是以 GET 苦求的参数只允许 ASCII 字符 ，而且浏览器会对 URL 的长度有落拓（HTTP公约本人对 URL长度并莫得作念任何章程）。

比如，你盛开我的著述，浏览器就会发送 GET 苦求给做事器，做事器就会复返著述的系数翰墨及资源。

把柄 RFC 表率，POST 的语义是把柄苦求负荷（报文body）对指定的资源作念出处理，具体的处理方式视资源类型而不同。POST 苦求佩戴数据的位置一般是写在报文 body 中，body 中的数据可以是恣意花样的数据，唯有客户端与做事端协商好即可，而且浏览器不会对 body 大小作念落拓。

比如，你在我著述底部，敲入了留言后点击「提交」（流露你们留言），浏览器就会试验一次 POST 苦求，把你的留言翰墨放进了报文 body 里，然后拼接好 POST 苦求头，通过 TCP 公约发送给做事器。

要是从 RFC 表率界说的语义来看：

GET 轨范等于安全且幂等的，因为它是「只读」操作，不管操作些许次，做事器上的数据都是安全的，且每次的死亡都是相通的。是以，可以对 GET 苦求的数据作念缓存，这个缓存可以作念到浏览器本人上（透澈幸免浏览器发苦求），也可以作念到代理上（如nginx），而且在浏览器中 GET 苦求可以保存为书签。

POST因为是「新增或提交数据」的操作，会修改做事器上的资源，是以是不安全的，且屡次提交数据就会创建多个资源，是以不是幂等的。是以，浏览器一般不会缓存 POST 苦求，也不成把 POST 苦求保存为书签。

GET 轨范等于安全且幂等的，因为它是「只读」操作，不管操作些许次，做事器上的数据都是安全的，且每次的死亡都是相通的。是以，可以对 GET 苦求的数据作念缓存，这个缓存可以作念到浏览器本人上（透澈幸免浏览器发苦求），也可以作念到代理上（如nginx），而且在浏览器中 GET 苦求可以保存为书签。

POST因为是「新增或提交数据」的操作，会修改做事器上的资源，是以是不安全的，且屡次提交数据就会创建多个资源，是以不是幂等的。是以，浏览器一般不会缓存 POST 苦求，也不成把 POST 苦求保存为书签。

关联词骨子历程中，设备者不一定会按照 RFC 表率界说的语义来兑现 GET 和 POST 轨范。比如：

可以用 GET 轨范兑现新增或删除数据的苦求，这样兑现的 GET 轨范当然就不是安全和幂等。

可以用 POST 轨范兑现查询数据的苦求，这样兑现的 POST 轨范当然等于安全和幂等。

可以用 GET 轨范兑现新增或删除数据的苦求，这样兑现的 GET 轨范当然就不是安全和幂等。

可以用 POST 轨范兑现查询数据的苦求，这样兑现的 POST 轨范当然等于安全和幂等。

客户端和做事端都可以发起四次挥手的历程，下图是客户端主动关闭衔接的历程：

具体历程：

客户端主动调用关闭衔接的函数，于是就会发送 FIN 报文，这个 FIN 报文代表客户端不会再发送数据了，插足 FIN_WAIT_1 情景；

做事端收到了 FIN 报文，然后随即恢复一个 ACK 说明报文，此时做事端插足 CLOSE_WAIT 情景。在收到 FIN 报文的时候，TCP 公约栈会为 FIN 包插入一个文献死亡符 EOF 到接纳缓冲区中，做事端应用模范可以通过 read 调用来感知这个 FIN 包，这个 EOF 会被放在已列队等候的其他已接纳的数据之后，是以必须要得不时 read 接纳缓冲区已接纳的数据；

接着，当做事端在 read 数据的时候，终末当然就会读到 EOF，接着read 就会复返 0，这时做事端应用模范要是独特据要发送的话，就发完数据后才调用关闭衔接的函数，要是做事端应用模范没独特据要发送的话，可以径直调用关闭衔接的函数，这时做事端就会发一个 FIN 包，这个 FIN 报文代表做事端不会再发送数据了，之后处于 LAST_ACK 情景；

客户端接纳到做事端的 FIN 包，并发送 ACK 说明包给做事端，此时客户端将插足 TIME_WAIT 情景；

做事端收到 ACK 说明包后，就插足了终末的 CLOSE 情景；

客户端经过 2MSL 时辰之后，也插足 CLOSE 情景；

客户端主动调用关闭衔接的函数，于是就会发送 FIN 报文，这个 FIN 报文代表客户端不会再发送数据了，插足 FIN_WAIT_1 情景；

做事端收到了 FIN 报文，然后随即恢复一个 ACK 说明报文，此时做事端插足 CLOSE_WAIT 情景。在收到 FIN 报文的时候，TCP 公约栈会为 FIN 包插入一个文献死亡符 EOF 到接纳缓冲区中，做事端应用模范可以通过 read 调用来感知这个 FIN 包，这个 EOF 会被放在已列队等候的其他已接纳的数据之后，是以必须要得不时 read 接纳缓冲区已接纳的数据；

接着，当做事端在 read 数据的时候，终末当然就会读到 EOF，接着read 就会复返 0，这时做事端应用模范要是独特据要发送的话，就发完数据后才调用关闭衔接的函数，要是做事端应用模范没独特据要发送的话，可以径直调用关闭衔接的函数，这时做事端就会发一个 FIN 包，这个 FIN 报文代表做事端不会再发送数据了，之后处于 LAST_ACK 情景；

客户端接纳到做事端的 FIN 包，并发送 ACK 说明包给做事端，此时客户端将插足 TIME_WAIT 情景；

做事端收到 ACK 说明包后，就插足了终末的 CLOSE 情景；

客户端经过 2MSL 时辰之后，也插足 CLOSE 情景；

为什么需要三次捏手？

若客户端发送的第一个 SYN 包因汇集蔓延淹留，后续从头发送 SYN 耕种衔接。此时若做事器仅用两次捏手（SYN+ACK），当淹留的旧 SYN 包到达做事器时，会被误认为是新苦求，导致做事器创建无效衔接（遽然资源）。三次捏手时，客户端收到旧 SYN 对应的 SYN+ACK 后，会因 seq 不符而驱逐，幸免无效衔接。

三次捏手确保两边的发送和接纳才气均被考据，幸免单标的通讯异常（如客户端能发但做事器接纳端口异常）。

若客户端发送的第一个 SYN 包因汇集蔓延淹留，后续从头发送 SYN 耕种衔接。此时若做事器仅用两次捏手（SYN+ACK），当淹留的旧 SYN 包到达做事器时，会被误认为是新苦求，导致做事器创建无效衔接（遽然资源）。三次捏手时，客户端收到旧 SYN 对应的 SYN+ACK 后，会因 seq 不符而驱逐，幸免无效衔接。

三次捏手确保两边的发送和接纳才气均被考据，幸免单标的通讯异常（如客户端能发但做事器接纳端口异常）。

为什么挥手需要四次？

当客户端发送 FIN 包苦求断开时，仅流露客户端不再发送新数据，但仍可能接纳做事器未传输完的数据（如做事器正在传输文献）。此时做事器需先恢复 ACK 说明收到 FIN，待自身数据发送收场后，再发送 FIN 包苦求断开，变成四次挥手。

若将挥手书化为两次（客户端 FIN→做事器 FIN+ACK），可能出现以下问题：做事器若有未发送完的数据，在恢复 FIN+ACK 后会被动关闭发送通说念，导致数据丢失。客户端收到 FIN+ACK 后立即关闭衔接，无法接纳做事器后续的数据。

当客户端发送 FIN 包苦求断开时，仅流露客户端不再发送新数据，但仍可能接纳做事器未传输完的数据（如做事器正在传输文献）。此时做事器需先恢复 ACK 说明收到 FIN，待自身数据发送收场后，再发送 FIN 包苦求断开，变成四次挥手。

若将挥手书化为两次（客户端 FIN→做事器 FIN+ACK），可能出现以下问题：做事器若有未发送完的数据，在恢复 FIN+ACK 后会被动关闭发送通说念，导致数据丢失。客户端收到 FIN+ACK 后立即关闭衔接，无法接纳做事器后续的数据。

低，这个查询方式是全表扫描的方式，因为左疲塌匹配的话，会导致索引失效，查询的时候无法附近索引。

MySQL的索引的数据结构是什么？红黑树和B+树后果高下？

MySQL InnoDB 引擎是用了B+树看成了索引的数据结构。

B+Tree 是一种多叉树，叶子节点才存放数据，非叶子节点只存放索引，而且每个节点里的数据是按主键限定存放的。每一层父节点的索引值都会出咫尺基层子节点的索引值中，因此在叶子节点中，包括了系数的索引值信息，何况每一个叶子节点都有两个指针，分别指向下一个叶子节点和上一个叶子节点，变成一个双向链表。

主键索引的 B+Tree 如图所示：

关于有 N 个叶子节点的 B+Tree，其搜索复杂度为O(logdN)，其中 d 流露节点允许的最大子节点个数为 d 个。在骨子的应用当中欧洲杯体育， d 值是大于100的，这样就保证了，即使数据达到千万级别时，B+Tree 的高度已经保管在 3～4 层傍边，也等于说一次数据查询操作只需要作念 3～4 次的磁盘 I/O 操作就能查询到指标数据。