今天挑选一篇腾讯的后台开发实习一面，给大家做讲解分析，参考回答和学习资料指引，期望对大家有所帮助～原贴链接感谢这位同学的分享，预祝后续Offer 多多～～面试题中，如果简历或项目没用过Flink的话，一般不会考察，所以这里也不做讲解开始吧～～～1.讲一下TCP三次握手 为什么要3次，两次或者四次不行吗解析：：TCP三次握手四次挥手，重点掌握参考回答：TCP 建立连接时，通过三次握手能防止历史连接的建立，能减少双方不必要的资源开销，能帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。不使用「两次握手」和「四次握手」的原因：「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。学习指引：理解学习：《小林coding》｜图解网络｜为什么是三次握手？不是两次、四次？2.讲一下常见的针对TCP的网络攻击？如何应对SYN flood攻击？解析：：推荐需要掌握。参考回答：SYN Flood攻击：这是一种利用TCP协议握手过程中的缺陷进行的攻击。攻击者发送大量的TCP SYN请求到目标服务器，但在收到服务器的SYN+ACK响应后并不发送最后的ACK确认，导致服务器上留下大量等待完成的半开连接，耗尽服务器资源，使得正常的TCP连接无法建立。TCP会话劫持:这种攻击方式是通过窃取TCP会话中的序列号等信息，然后冒充合法用户接入到会话中。攻击者可以监听网络上的TCP会话，分析并预测序列号，然后发送伪造的数据包，中断或篡改原有的会话内容。TCP重置攻击: 在这种攻击中，攻击者发送伪造的TCP RST（重置）数据包到目标主机，中断正常的TCP连接。由于TCP协议的设计，当接收到RST数据包时，连接的两端都会关闭连接，这使得攻击者可以成功地中断服务或进行拒绝服务攻击。如何应对SYN flood攻击？启用SYN Cookie技术：SYN Cookie是一种无状态的TCP连接技术，它通过计算一个独特的Cookie来验证TCP连接的合法性，而不需要在服务器上保存每个连接的状态信息。当服务器收到SYN请求时，它会计算一个Cookie并发送给客户端，客户端在后续的ACK报文中携带该Cookie，服务器通过验证Cookie的有效性来判断连接是否合法。这样可以有效减少服务器资源的消耗，并防止SYN flood攻击导致的资源耗尽。调整TCP协议栈参数：通过调整TCP协议栈的参数，可以优化服务器的性能和防御SYN flood攻击。例如，可以减小SYN Timeout时间，使服务器更快地释放无效的连接请求；增大TCP连接的队列长度，提高服务器处理连接请求的能力；启用TCP Fast Open等特性，加快TCP连接的建立过程。使用防火墙或入侵检测系统（IDS）：防火墙或IDS可以监控网络流量，并识别出异常的SYN请求流量。它们可以根据预设的规则对恶意流量进行过滤或限制，从而保护服务器免受SYN flood攻击的侵害。学习指引：面试学习：《JavaGuild》|网络攻击常见手段总结3.讲一下TCP的TIME_WAIT状态，如果服务器中存在大量的这个状态应该怎么排查？解析：：系统掌握TCP的三次握手四次挥手相关内容，再按自己理解回答这个问题。参考回答：介绍TIME_WAIT状态：当TCP连接的一方（通常是客户端）主动关闭连接时，会发送一个FIN包给对方，表示希望关闭连接。服务端通常会回一个ACK确认包。当服务端也完成发送后，会再次发送一个FIN包给客户端，此时客户端接收到FIN后会回复一个ACK给服务端，之后客户端会进入TIME_WAIT状态。在TIME_WAIT状态下，连接会保持一段时间（通常是2MSL，即最大报文段生存时间的两倍），以确保在网络中延迟的数据包能够被正确处理如何排查TIME_WAIT确认TIME_WAIT状态的数量：使用netstat命令来查看当前TCP连接的状态分布。例如，运行netstat -nat | grep TIME_WAIT | wc -l可以查看TIME_WAIT状态的连接数。查看系统TCP参数：使用sysctl -a | grep tcp命令可以查看系统中与TCP相关的内核参数设置，特别关注net.ipv4.tcp_tw_reuse、net.ipv4.tcp_tw_recycle（在某些情况下可能不推荐启用）和net.ipv4.tcp_fin_timeout等参数的设置。分析网络连接和应用程序行为：确定哪些应用程序或服务正在产生大量的TIME_WAIT连接。使用netstat -natp可以查看每个连接的进程ID和程序名称。检查网络问题和延迟：网络问题或延迟可能导致连接不能正常关闭，从而产生大量的TIME_WAIT状态。使用网络诊断工具（如ping、traceroute等）来检查网络状况。学习指引：《知乎》｜运维排查篇 服务器产生大量的TIME_WAIT的原因你知道吗？4.如果项目中出现CPU占用过高的情况，该怎么排查和处理？解析：：高频面试题，需要掌握参考回答：在Linux环境下，项目出现CPU占用过高的情况时，可以按照以下步骤进行排查和处理：定位高CPU占用的进程：使用top命令查看系统中CPU占用率最高的进程。分析进程中的线程：如果发现某个进程的CPU占用率特别高，可以使用top -H -p [PID]来查看该进程中各个线程的CPU占用情况。找出占用CPU最高的线程ID。转换线程ID为16进制：使用printf "%x\n" [线程ID]命令将线程ID转换为16进制格式。获取线程堆栈信息：使用jstack [进程PID] | grep [线程ID的16进制] -A 30命令获取该线程的Java堆栈信息（如果是Java进程）。这可以帮助定位到具体的代码行或方法调用。如果不是Java进程，可以使用gdb或其他相应的调试工具来获取线程的堆栈信息。分析代码和日志：根据堆栈信息，检查相关的代码逻辑，看是否有死循环、资源泄露、复杂计算等导致CPU占用过高的问题。同时检查应用程序的日志，看是否有异常或错误信息与高CPU占用相关。处理措施：如果是代码问题，修复相应的bug或优化算法。如果是配置问题，调整系统或应用程序的配置参数。如果是资源不足，考虑增加硬件资源或优化资源分配。如果是外部攻击，加强系统的安全防护措施。学习指引：博客｜线上高CPU占用、高内存占用排查思路5.介绍一下Linux常见命令？top命令具体是做什么的？解析：：linux 常用命令需要掌握，top就是最简单最重要的的之一参考回答：大家记忆一些，根据记忆回答就行，例如chmod：更改文件或目录的权限。cat：查看文件内容。......top命令具体是做什么的？top命令，它是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况.该命令可以提供实时的对系统处理器的状态监视，它会显示系统中CPU最“敏感”的任务列表，并且可以按CPU使用、内存使用和执行时间对任务进行排序学习指引：面试常考21条Linux命令一周学会Linux6.讲一下HashMap，为什么HashMap要引入红黑树？为什么树化的默认节点是8？如果不用红黑树如何处理过长的链表？解析：：HashMap是Java容器最高频的面试点。参考回答：为什么HashMap要引入红黑树？引入之前，当发生哈希冲突时，数据是以链表的形式进行存储的，如果冲突严重，链表就会过长，链表O（N）的复杂度性能太差。用红黑树期望是把复杂度降到O（log n）为什么树化的默认节点是8？根据JDK 设计者的解释：和hashcode碰撞次数的泊松分布有关，主要是为了寻找一种时间和空间的平衡。红黑树中的TreeNode是链表中的Node所占空间的2倍，虽然红黑树的查找效率为o(logN)，要优于链表的o(N)，但是当链表长度比较小的时候，即使全部遍历，时间复杂度也不会太高。固，要寻找一种时间和空间的平衡，即在链表长度达到一个阈值之后再转换为红黑树。之所以是8，是因为Java的源码贡献者在进行大量实验发现，hash碰撞发生8次的概率已经降低到了0.00000006，几乎为不可能事件，如果真的碰撞发生了8次，那么这个时候说明由于元素本身和hash函数的原因，此时的链表性能已经已经很差了，操作的hash碰撞的可能性非常大了，后序可能还会继续发生hash碰撞。所以，在这种极端的情况下才会把链表转换为红黑树.如果不用红黑树如何处理过长的链表？使用其他数据结构:除了红黑树之外，还可以考虑使用其他数据结构来优化长链表的问题。例如，可以使用平衡树（如 AVL 树）、B树或B+树等。这些数据结构都可以在 O(log n) 的时间复杂度内完成查找、插入和删除操作.学习指引：系统学习：《JavaGuide》| HashMap 源码分析面试题学习：博客｜HashMap的树化门槛为什么是81.HashMap是线程安全的吗？如果不是那什么是？为什么ConcurrentHashMap是线程安全的？是如何实现线程安全的呢？解析：：面试常见套路，先问HashMap 再 问 ConcurrentHashMap。 关于线程安全的实现，一般会结合JDK1.7和JDK1.8一起来回答，当然也可以只回答JDK1.8,如果面试官问到1.7你再回答。所以需要两个版本一起掌握参考回答：HashMap 不是现成安全的，需要保证现成安全的话，推荐使用ConcurrentHashMap。如何实现线程安全的？JDK 1.7中的ConcurrentHashMap通过分段锁（Segmentation）实现线程安全。它将整个哈希表分成多个段（Segment），每个段都是一个小的哈希表，并且拥有自己的锁。这样，多个线程可以并发地访问不同的段，从而减少了锁的竞争，提高了并发性能。JDK 1.8中的ConcurrentHashMap则采用了完全不同的设计。它摒弃了分段锁的概念，转而使用了一种更细粒度的锁策略，结合CAS（Compare-and-Swap）无锁算法来实现线程安全。在JDK 1.8中，ConcurrentHashMap将整个哈希表看作一个整体，不再进行分段。而是通过数组+链表+红黑树的结构来存储数据，并使用Synchronized和CAS来协调并发访问。学习指引：面试学习：《JavaGuide》｜ConcurrentHashMap 源码分析1.介绍一下Base64编码的原理，为什么Base64编码会使数据体积变大33%？解析：：不太高频。推荐了解掌握。参考回答：Base64编码是:一种基于64个可打印字符来表示二进制数据的方法。其编码原理是将一个8位字节序列拆散为6位的片段，并为每个6位的片段分配一个字符，这64个字符包括小写字母a-z、大写字母A-Z、数字0-9、符号"+"和"/"。实际上，还有一个垫字符"="，用于编码后的数据长度不是4的倍数时进行填充，因此严格来说有65个字符。Base64编码会使数据体积变大33%左右的原因:在于其编码方式。原始的二进制数据是按照8位一个字节进行存储的，而Base64编码将其拆分为6位一组，并用一个字符表示。这样，原本3个字节（24位）的数据被编码成了4个字符（每个字符8位，共32位）。因此，编码后的数据长度大约是原始数据长度的4/3，即增加了约33%。学习指引：了解学习：Base64编码使数据量变大的原因详解1.为什么Redis Pub/Sub比Kafka更快一些？二者之间如何选取？解析：：频率一般，推荐掌握。重在理解redis本身特点和Kafka的实现原理。然后推导回答，不要背。参考回答：为什么Redis Pub/Sub比Kafka更快一些？Redis是一个内存数据库，其Pub/Sub功能将消息保存在内存中。由于内存访问速度通常远快于磁盘访问速度，因此Redis在处理实时性较高的消息推送时具有优势。此外，Redis的Pub/Sub模型相对简单，使得它在处理发布和订阅操作时的开销较小。然而，Kafka是一个完整的系统，提供了高吞吐量、分布式的提交日志。它旨在处理大规模数据流，具有强大的持久化能力和容错性。Kafka的分布式架构和分区机制使得它能够在多个消费者之间实现负载均衡，从而提高整体处理能力。二者之间如何选取？Redis PUB/SUB使用场景：消息持久性需求不高吞吐量要求不高可以忍受数据丢失数据量不大Kafka使用场景：(上面以外的其他场景)高可靠性高吞吐量持久性高多样化的消费处理模型学习指引：面试学习：《知乎》｜Redis与Kafka的区别1.Kafka是如何做到数据持久化的？解析：：Kafka相关高频面试题，Kafka重要原理知识点之一，推荐掌握参考回答：Kafka把Topic中一个Partition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完成的文件，减少磁盘占用通过索引信息可以快速定位Message和确定response的最大大小通过将索引元数据全部映射到 memory，可以避免 Segment 文件的磁盘I/O操作通过索引文件稀疏存储，可以大幅降低索引文件元数据占用空间大小学习指引：面试学习：《40 道精选 Kafka 面试题》本文也是 《热门面经讲解》专栏 系列文章之一，文末尾有专栏链接，大家可以点个关注，我会持续更新～～