小红书后端开发二面面经：最长递增子序列、TCP 与 UDP、进程与线程

《面试题目》

1. 手撕算法题：最长递增子序列。
2. TCP 和 UDP 有什么区别？
3. 进程和线程的区别与联系是什么？
4. 请介绍一下你做的项目（展示项目）。

《参考解析》

最长递增子序列（LIS）：先把「子序列」的定义讲清楚。 子序列不要求连续，只要求相对顺序不变，这是和「最长递增子数组」最容易混的地方，说错定义整道题就跑了。常规解法是 dp[i] 表示以 nums[i] 结尾的最长递增长度，转移为 dp[i] = max(dp[j]) + 1（j < i 且 nums[j] < nums[i]），时间 O(n²)。更优的做法是维护一个「长度为 k 的递增子序列的最小结尾值」数组 tails，它本身单调递增，于是可以用二分查找定位替换位置：遍历每个数，在 tails 里找第一个大于等于它的位置替换掉，找不到就追加，最终 tails 的长度就是答案，时间 O(n log n)、空间 O(n)。注意 tails 不是某个真实子序列，所以「重建具体序列」需要额外记录前驱下标；如果是求最长非递减，二分的比较要改成严格大于。工程上还有个取舍：要输出长度只维护 tails 就够，要输出序列本身就用 dp + 前驱数组，别为了省空间把可回放的信息丢掉。

TCP 与 UDP：围绕「要不要为可靠性付代价」展开。 TCP 面向连接、提供可靠有序的字节流，靠三次握手建连、序号与确认、超时重传、滑动窗口做流量控制、拥塞控制（慢启动 / 拥塞避免 / 快重传快恢复）保证「不丢、不重、不乱」，代价是连接状态、首部开销（20 字节起）和延迟；UDP 无连接、不保证可靠与顺序，首部只有 8 字节，把可靠性交给应用层，适合实时音视频、游戏、DNS 这类「宁可丢一点也不要等」的场景。回答时值得补一句演进：HTTP/3 跑在 QUIC 上，底层是 UDP，但在用户态自己实现了重传、有序交付与拥塞控制——说明「UDP 不可靠」不等于「UDP 做不了可靠传输」，只是把成本从协议栈挪到了应用层。

进程与线程：资源分配单位和调度单位。 进程是资源分配的基本单位，拥有独立的虚拟地址空间、文件描述符表、信号处理等；线程是 CPU 调度的基本单位，同进程内线程共享地址空间和大部分资源，只各自持有栈、寄存器上下文和线程局部存储。因此线程切换不需要换页表、开销远小于进程切换；通信上一根进程内的线程直接读写共享内存加同步即可，跨进程要走管道、共享内存、消息队列、socket 等 IPC，成本更高。代价是隔离性：一个线程段错误会带崩整个进程，进程之间则相对隔离；另外线程数不是越多越好，上下文切换、锁竞争和内存占用（每个线程的栈）都会成为瓶颈，所以有栈大小与线程池参数的取舍。可以顺一句「为什么用线程池」：把创建销毁的成本摊掉，并用队列和拒绝策略把突发流量挡在可控范围内。

项目展示：二十分钟的面试里，讲法比内容更值钱。 这类短面试的项目环节通常只有几分钟，面试官要的是「判断你是不是真的做过」，所以结构上先一句话交代背景与目标，再说明你负责的模块、技术选型和关键指标，最后挑一个真正的难点讲清「现象—排查—方案—结果」。数字要能解释口径（吞吐、P99 延迟、数据规模），不能解释的数字反而减分；被追问「这块是你独立做的吗」时要如实区分自己写的和别人写的部分，面试官几乎都会顺着边界继续问。原帖的节奏也值得留意：二面二十多分钟结束、当天三四个小时就来了 HR 联系，说明短不等于凉——面试时长和结果没有必然关系，反问环节把业务方向、团队职责、后续流程问清楚，比自己猜有用。