面经笔记+来自腾讯后台开发内推2019

红太狼 2022-05-29 01:27 222阅读 0赞

## 线程里面有什么是独立的？ ##

进程包含代码数据文件，这个是进程内的所有线程共享，但是线程有自己的线程ID、程序计数器、寄存器和栈独立的资源。

## 一个进程一定要有一个线程吗？没有线程的进程是什么？ ##

## 协程是什么？ ##

**协程**是在线程之上由“用户”构建的并发单元，对OS来说无感知，协程的切换由用户自己管理和调度。（这里的用户是相较于内核而言的，一些通用库这里也理解为用户）

## 同步和互斥是怎么做的？ ##

## 线程间的同步和互斥是怎么做的？ ##

## 守护进程和僵尸进程，孤儿进程有什么了解？ ##

Linux Daemon（守护进程）是运行在后台的一种特殊进程。它独立于控制终端并且周期性地执行某种任务或等待处理某些发生的事件。它不需要用户输入就能运行而且提供某种服务，不是对整个系统就是对某个用户程序提供服务。Linux系统的大多数服务器就是通过守护进程实现的。常见的守护进程包括系统日志进程syslogd、 web服务器httpd、邮件服务器sendmail和数据库服务器mysqld等。

守护进程一般在系统启动时开始运行，除非强行终止，否则直到系统关机都保持运行。守护进程经常以超级用户（root）权限运行，因为它们要使用特殊的端口（1-1024）或访问某些特殊的资源。

一个守护进程的父进程是init进程，因为它真正的父进程在fork出子进程后就先于子进程exit退出了，所以它是一个由init继承的孤儿进程。守护进程是非交互式程序，没有控制终端，所以任何输出，无论是向标准输出设备stdout还是标准出错设备stderr的输出都需要特殊处理。

守护进程的名称通常以d结尾，比如sshd、xinetd、crond等

参考这个链接[守护进程详解及创建，daemon()使用][daemon]

**孤儿进程：**一个父进程退出，而它的一个或多个子进程还在运行，那么那些子进程将成为孤儿进程。孤儿进程将被init进程(进程号为1)所收养，并由init进程对它们完成状态收集工作。

**僵尸进程：**一个进程使用fork创建子进程，如果子进程退出，而父进程并没有调用wait或waitpid获取子进程的状态信息，那么子进程的进程描述符仍然保存在系统中。这种进程称之为僵死进程。

## 系统出现僵尸进程，为什么产生和怎么解决？ ##

参考这个链接[孤儿进程与僵尸进程\[总结\]][Link 1]

## 软连接和硬连接了解吗？硬连接和软连接删了，原对象会如何？ ##

参考这个博客[这里写链接内容][Link 2]

## 硬连接和软连接的底层原理？ Inode是什么？ ##

参考这个博客[这里写链接内容][Link 3]

## 强类型和弱类型，静态类型动态类型是什么？ ##

## TCP/UDP的了解？Tcp和udp的使用场景？Tcp的time\_wait ##

## Tcp粘包 ##

TCP断包就是因为最大报文段长度的存在，当消息长度过大，，那么tcp就会将其分片，然后每片被tcp封装，然后由ip封装，最后被传输到接收端，这样子当接收端接收到消息后，就会不清楚这是不是一个完整的消息。

粘包则是因为为了提高网络利用率，当传输层发现传输的数据长度太小时，会等待多个消息一起发送，这时候就会提高网络利用率，但是当接收端接收过以后，会不知道这是一个完整的消息，还是多个消息在一起。从而有可能将其作为一个消息来处理。nagle算法就是实现的这个功能。

对于断包和粘包的通常处理方法为将消息封装为一定的格式，例如每个消息头部为aa，尾部为55，或者将整个消息的有效长度标明，这样子当接收端接收到消息之后，就可以以此来分辨消息是不是我完整的。

而对于断包和粘包的通常处理方法为将消息封装为一定的格式，例如每个消息头部为aa，尾部为55，或者将整个消息的有效长度标明，这样子当接收端接收到消息之后，就可以以此来分辨消息是不是我完整的。

\*\*什么是粘包现象？\*\*TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。  
**为什么出现粘包现象？**  
　　（1）发送方原因  
　　我们知道，TCP默认会使用Nagle算法。而Nagle算法主要做两件事：1）只有上一个分组得到确认，才会发送下一个分组；2）收集多个小分组，在一个确认到来时一起发送。所以，正是Nagle算法造成了发送方有可能造成粘包现象。  
　　（2）接收方原因。TCP接收到分组时，并不会立刻送至应用层处理，或者说，应用层并不一定会立即处理；实际上，TCP将收到的分组保存至接收缓存里，然后应用程序主动从缓存里读收到的分组。这样一来，如果TCP接收分组的速度大于应用程序读分组的速度，多个包就会被存至缓存，应用程序读时，就会读到多个首尾相接粘到一起的包。  
**什么时候需要处理粘包现象**  
（1）如果发送方发送的多个分组本来就是同一个数据的不同部分，比如一个很大的文件被分成多个分组发送，这时，当然不需要处理粘包的现象；  
（2）但如果多个分组本毫不相干，甚至是并列的关系，我们就一定要处理粘包问题了。比如，我当时要接收的每个分组都是一个有固定格式的商品信息，如果不处理粘包问题，每个读进来的分组我只会处理最前边的那个商品，后边的就会被丢弃。这显然不是我要的结果。  
**如何处理粘包现象**  
1）发送方：对于发送方造成的粘包现象，我们可以通过关闭Nagle算法来解决，使用TCP\_NODELAY选项来关闭Nagle算法。  
（2）接收方 遗憾的是TCP并没有处理接收方粘包现象的机制，我们只能在应用层进行处理。  
（3）应用层处理：应用层的处理简单易行！并且不仅可以解决接收方造成的粘包问题，还能解决发送方造成的粘包问题。

解决方法就是循环处理：应用程序在处理从缓存读来的分组时，读完一条数据时，就应该循环读下一条数据，直到所有的数据都被处理；但是如何判断每条数据的长度呢？

两种途径：

1）格式化数据：每条数据有固定的格式（开始符、结束符），这种方法简单易行，但选择开始符和结束符的时候一定要注意每条数据的内部一定不能出现开始符或结束符；

2）发送长度：发送每条数据的时候，将数据的长度一并发送，比如可以选择每条数据的前4位是数据的长度，应用层处理时可以根据长度来判断每条数据的开始和结束。

(18) http1.0和1.1有什么区别

(19) https协议？原理？端到端中间的过程。

(20) 对称加密和非对称加密？

(21) Cookies和session的关系

(22) Cookies的最大保存时间

(23) Mysql索引的原理，底层是怎么存的？

(24) 主键和唯一键有什么区别？

(25) Varchar和char的区别？

(26) UTF-8下面varchar能占多少字符？GBK呢？

(27) 说下你知道的排序，比较一下他们的优缺点，复杂度和应用场景。

[daemon]: https://www.cnblogs.com/mickole/p/3188321.html
[Link 1]: https://www.cnblogs.com/Anker/p/3271773.html
[Link 2]: http://blog.csdn.net/jackzhang_123/article/details/79424390
[Link 3]: https://www.cnblogs.com/youxin/p/3553225.html