本面经地址来自海康威视 C++应用软件开发 一面二面三面面经 C++多态 面向对象的三大特征：封装，继承，多态 1.封装：将数据和操作数据的方法1进行有机结合，隐藏对象的属性和实现细节，仅对外公开接口来和对象进行交互。 2.继承：可以使用现有类的所有功能，并在不需要重新编写原来的类的情况下对这些功能仅从扩展 三种继承方式 继承方式 private继承 protected继承 public继承 基类的private成员 不可见 不可见 不可见 基类的protected成员 变为private成员 仍为protected成员 仍为protected成员 基类的public成员 变为private成员 变为protected成员 仍为public成员仍为public成员 3.多态： 用父类型的指针指向子类型的实例，然后通过父类的指针调用实际子类的成员函数。实现多态， 有两种方式，重写，重载。 内存分区： 内存分配方式： 在C++中，内存分为五个区，它们分别是堆，栈，自由存储区，全局/静态存储区和常量存储区 堆，由程序员进行分配释放，就是那些由new分配的内存块，一般一个new对应一个delete 栈，由操作系统自动分配释放，存放函数的参数值，局部变量的值等，函数结束时这些存储单元被自动的释放 自由存储区，就是由malloc分配的内存块，一般一个malloc对应一个free 全局/静态存储区：全局变量和静态变量被分配在同一块内存中 常量存储区：这是一块比较特殊的存储区，里面存储的是常量，不允许修改 静态成员函数可以直接访问非静态数据成员吗？ 不可以，静态成员函数只是和类实现了绑定，而没有和任何对象绑定在一起，不包含this指针，无法访问静态成员。（静态成员函数所需内存在程序执行前就分配好了，给静态成员必须要等到这个类在堆/栈上分配内存才能使用，所以如果静态成员函数访问非静态，可能非静态成员还没有内存） socket编程了解吗？ 服务器端函数： socket创建一个套接字 bind绑定ip和端口 listen使套接字变为可以被动链接 accept等待客户端的连接 read/write接收发送数据 close关闭连接 客户端函数： 创建一个socket，用socket（） 连接服务器用connect（） 收发数据用read/write（) close关闭连接 TCP四次挥手的close_wait状态是在什么时候？出现大量close_wait有什么影响，怎么排查？ 客户端打算关闭连接，此时会发送一个TCP报文，FIN标志被置为1，之后客户端进入FIN_wait_1状态 服务端收到该报文后，向客户端发送ACK报文，接着服务器进入CLOSED_WAIT状态 客户端收到服务端的ACK报文之后，进入FIN_wait_2状态 等待客户端处理完数据后，也向客户端发送FIN报文，之后服务端进入LAST_ACK状态 客户端收到服务器的FIN报文后，回一个ACK应答报文，之后进入TIME_WAIT状态 服务器接收到ACK应答报文后，就进入CLOSED状态，至此服务端已经完成连接的关闭 客户端在经过2MSL等待时间之后，自动进入CLOSED状态，至此客户端也完成连接的关闭 出现大量CLOSE_WAIT的原因及解决办法： 如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。这种情况通过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行。所以如果将大量CLOSE_WAIT的解决办法总结为一句话那就是：查代码。因为问题出在程序里头啊。 IO多路复用了解吗？select有什么问题？1024能够修改吗？ 一个进程虽然任意时刻只能处理一个请求，但是处理每个请求的时间很短，1s就可以处理很多请求，把时间拉长来看，多个请求复用了一个进程，这就是多路复用。 select实现多路复用的方式是，将已连接的Socket都放入到一个文件描述符集合，然后调用select函数将文件描述符拷贝到内核里，让内核来检验是否有事件产生，检查的方式很粗暴，就是通过遍历文件描述符集合的方式，当检查到有事件产生后，将该Socket标记为可读或可写，接着再将整个文件描述符集合拷贝回用户态，然后用户态再通过遍历的方法找到可读或者可写的Socket，然后对其处理。 多线程有哪些锁，读写锁有什么特点 互斥锁，自旋锁，读写锁，乐观锁，悲观锁 互斥锁与自旋锁 加锁的目的是保证共享资源在任意时间里，只有一个线程访问，这样就可以避免多线程导致共享数据错乱的问题 当已经有一个线程加锁后，其他线程加锁则就会失败，互斥锁和自旋锁对于加锁失败后的处理方式是不一样的： ​    互斥锁加锁失败后，线程会释放 CPU ，给其他线程； ​    自旋锁加锁失败后，线程会忙等待，直到它拿到锁； 互斥锁是一种「独占锁」，比如当线程 A 加锁成功后，此时互斥锁已经被线程 A 独占了，只要线程 A 没有释放手中的锁，线程 B 加锁就会失败，于是就会释放 CPU 让给其他线程，既然线程 B 释放掉了 CPU，自然线程 B 加锁的代码就会被阻塞。 对于互斥锁加锁失败而阻塞的现象，是由操作系统内核实现的。当加锁失败时，内核会将线程置为「睡眠」状态，等到锁被释放后，内核会在合适的时机唤醒线程，当这个线程成功获取到锁后，于是就可以继续执行。如下图： 所以，互斥锁加锁失败时，会从用户态陷入到内核态，让内核帮我们切换线程，虽然简化了使用锁的难度，但是存在一定的性能开销成本。 那这个开销成本是什么呢？会有两次线程上下文切换的成本： 当线程加锁失败时，内核会把线程的状态从「运行」状态设置为「睡眠」状态，然后把 CPU 切换给其他线程运行； 接着，当锁被释放时，之前「睡眠」状态的线程会变为「就绪」状态，然后内核会在合适的时间，把 CPU 切换给该线程运行。  线程的上下文切换的是什么？当两个线程是属于同一个进程，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据。 上下切换的耗时有大佬统计过，大概在几十纳秒到几微秒之间，如果你锁住的代码执行时间比较短，那可能上下文切换的时间都比你锁住的代码执行时间还要长。 所以，如果你能确定被锁住的代码执行时间很短，就不应该用互斥锁，而应该选用自旋锁，否则使用互斥锁。 自旋锁是通过CPU提供的CAS（Compare And Swap）函数，在用户态完成加锁和解锁的操作，不会主动产生线程上下文切换，所以相比互斥锁，会快一点，开销也小一点 一般加锁的过程，包含两个步骤： 第一步，查看锁的状态，如果锁是空闲的，则执行第二步； 第二步，将锁设置为当前线程持有； CAS 函数就把这两个步骤合并成一条硬件级指令，形成原子指令，这样就保证了这两个步骤是不可分割的，要么一次性执行完两个步骤，要么两个步骤都不执行。 比如，设锁为变量 lock，整数 0 表示锁是空闲状态，整数 pid 表示线程 ID，那么 CAS(lock, 0, pid) 就表示自旋锁的加锁操作，CAS(lock, pid, 0) 则表示解锁操作。 使用自旋锁的时候，当发生多线程竞争锁的情况，加锁失败的线程会「忙等待」，直到它拿到锁。这里的「忙等待」可以用 while 循环等待实现，不过最好是使用 CPU 提供的 PAUSE 指令来实现「忙等待」，因为可以减少循环等待时的耗电量。 自旋锁是最比较简单的一种锁，一直自旋，利用 CPU 周期，直到锁可用。需要注意，在单核 CPU 上，需要抢占式的调度器（即不断通过时钟中断一个线程，运行其他线程）。否则，自旋锁在单 CPU 上无法使用，因为一个自旋的线程永远不会放弃 CPU。 自旋锁开销少，在多核系统下一般不会主动产生线程切换，适合异步、协程等在用户态切换请求的编程方式，但如果被锁住的代码执行时间过长，自旋的线程会长时间占用 CPU 资源，所以自旋的时间和被锁住的代码执行的时间是成「正比」的关系，我们需要清楚的知道这一点。 自旋锁与互斥锁使用层面比较相似，但实现层面上完全不同：当加锁失败时，互斥锁用「线程切换」来应对，自旋锁则用「忙等待」来应对。 读写锁 读写锁由【读锁】和【写锁】组成，只读取共享资源1用【读锁】加锁，如果要修改共享资源则用【写锁】加锁。 读写锁的工作原理是： ​    当【写锁】没有被线程占用时，【读锁】可以多线程并发持有 ​    当【写锁】被线程占用时，读线程的获取读锁的操作会被阻塞，其他写线程的获取写锁的操作也会被阻塞 乐观锁和悲观锁 悲观锁做事比较悲观，它认为多线程同时修改共享资源的概率比较高，于是很容易出现冲突，所以访问共享资源前，先要上锁。 那相反的，如果多线程同时修改共享资源的概率比较低，就可以采用乐观锁。 乐观锁做事比较乐观，它假定冲突的概率很低，它的工作方式是：先修改完共享资源，再验证这段时间内有没有发生冲突，如果没有其他线程在修改资源，那么操作完成，如果发现有其他线程已经修改过这个资源，就放弃本次操作。 分布式有了解吗？ 不太清楚