这篇文章记述了关于字节和腾讯提前批面试的知识点。
字节和腾讯一上来先问实习项目，问用户随意产生一个token可以访问 metaserver 吗？ metaserver 怎么降低信息变更时的抖动啊（用减少负载，具体怎么减少也不知道：减少查数据库次数，使用缓存等）；长轮询怎么保证报文推送给对应的网关啊？感觉这块讲的不是很清楚，得仔细捋清楚了使劲拖面试官的时间才行，不然这块不拖住他就会跑去问基础去了；
问完项目就是聊计算机基础：
操作系统相关：
讲一下 malloc 的工作机制？
首先会扫描之前由 free() 释放的空闲内存块列表，找到尺寸大于或者等于要求的一块空闲内存。如果这一块内存和所要求的相当就返回内存块地址。若是一块较大的内存就对其进行分割，剩下的那块空闲内存保留在空闲列表里。如果空闲列表里没有足够大的空闲内存块，那么 malloc() 就会调用 sbrk() 以分配更多的内存。由于 sbrk() 是系统调用要陷入内核，为了减少对 sbrk() 的调用次数， malloc() 并未只是严格按照所需字节数来分配内存，而是以更大的幅度（虚拟内存页大小的倍数 4K）来增加 program break，并将超出部分置于空闲内存列表中。
malloc 分配会导致缺页中断吗？
malloc 分配的是虚拟内存，会涉及到缺页中断。
打开一个文件的过程是什么样的？
要打开一个文件，会有文件名。操作系统根据文件名a，在系统文件打开表中查找。
第一种情况：
如果文件a已经打开，则在进程文件打开表中为文件a分配一个表项，然后将该表项的指针指向系统文件打开表中和文件a对应的一项;
然后再PCB中为文件分配一个文件描述符fd，作为进程文件打开表项的指针,文件打开完成。
第二种情况：
如果文件a没有打开，查看含有文件a信息的目录项是否在内存中，如果不在，将目录表装入到内存中，作为cache；
根据目录表中文件a对应项找到 inode 在磁盘中的位置；
将文件a的 inode 装入到内存中的Active inode中；
然后在系统文件打开表中为文件a增加新的一个表项，将表项的指针指向Active Inode中文件a的FCB；
然后在进程的文件打开表中分配新的一项，将该表项的指针指向系统文件打开表中文件a对应的表项；
然后在PCB中，为文件a分配一个文件描述符fd，作为进程文件打开表项的指针,文件打开完成。
一个进程打开一个文件在写，另外一个进程打开同一个文件进行删除，这样可以删除吗？
Linux中多进程环境下，打开同一个文件，当一个进程进行读写操作，如果另外一个进程删除了这个文件，那么读写该文件的进程会发生什么呢?
因为文件被删除了，读写进程发生异常?
正在读写的进程仍然正常读写，好像没有发生什么？
学操作系统原理的时候，我们知道，linux是通过link的数量来控制文件删除，只有当一个文件不存在任何link的时候，这个文件才会被删除。而每个文件都会有2个link计数器i_count 和 i_nlink。i_count的意义是当前使用者的数量，也就是打开文件进程的个数。i_nlink的意义是介质连接的数量；或者可以理解为 i_count是内存引用计数器，i_nlink是硬盘引用计数器。再换句话说，当文件被某个进程引用时，i_count 就会增加；当创建文件的硬连接的时候，i_nlink 就会增加。
对于 rm 而言，就是减少 i_nlink。这里就出现一个问题，如果一个文件正在被某个进程调用，而用户却执行 rm 操作把文件删除了，会出现什么结果呢？
当用户执行 rm 操作后，ls 或者其他文件管理命令不再能够找到这个文件，但是进程却依然在继续正常执行，依然能够从文件中正确的读取内容。这是因为，rm 操作只是将 i_nlink 置为 0 了；由于文件被进程引用的缘故，i_count 不为 0，所以系统没有真正删除这个文件。i_nlink 是文件删除的充分条件，而 i_count 才是文件删除的必要条件。
基于以上只是，大家猜一下，如果在一个进程在打开文件写日志的时候，手动或者另外一个进程将这个日志删除，会发生什么情况？
虽然日志文件被删除了，但是有一个进程已经打开了那个文件，所以向那个文件中的写操作仍然会成功，数据仍然会提交。
下面，告诉大家如何恢复那个删除的文件。
例如，你删除了tcpdump.log，执行lsof | grep tcpdump.log，你应该能看到这样的输出：
tcpdump 2864 tcpdump 4w REG 253,0 0 671457 /root/tcpdump.log (deleted)
然后：
cp /proc/2864/fd/4 /root/tcpdump.log
网络相关：
四次挥手为什么是四次？三次不行吗？被动关闭方是个什么流程？FIN 报文代表什么意思？
我先开始以为是解释最后一次ACK 的必要性，结果他的意思是解释一下服务器为啥会有 close_wait 状态。其实就是讲服务器要等做完工作了才能给客户端发送 FIN 报文，这个报文的意思是 “我做完了”。由此引申出为啥要三次握手，两次不行吗？—两次的话会造成这样一种后果：客户端发送SYN请求给服务端，结果在网络中滞留了很长时间，到服务端的时候可能客户端都重新干别的事去了。这个时候服务端一接收到 SYN，赶紧给客户端发 SYN ACK，结果因为没有第三次握手，它不知道客户端此时已经不再需要连接了，然后服务端就傻傻的等到超时，这对宝贵的服务端资源来说是不可忍受的。所以会有三次握手的存在。2021-07-17写
一个 1M 大小的文件使用 TCP 协议传输到对端，分析下时间消耗的维度，怎么可以减少时间的消耗？
这块属于开放性的问题，不知道咋回答。只能从报文分片，三次握手，确认应答等维度进行回答。减少时间消耗的话，面试官说如果采用长连接可以省却三次握手，分片也可以减少时间。
HTTP 协议怎么保持长连接？知道哪几种 HTTP 协议版本？HTTP1.X 和 HTTP2.X 的区别，HTTP3 了解吗？
拥塞控制的算法
拥塞控制和流量控制的区别
数据库相关：
数据结构算法相关：
hashmap 同时多个线程进行写操作该怎么做？
设计题：
设计一个5秒钟的定时任务怎么设计？