。

比如通过线程池、非阻塞I/O、事件驱动机制#xff08;如epoll#xff09;#xff0c;Web服务器…TinyWebSever项目面试题整理

1.为什么要做这样一个项目

满足高并发和高性能需求现代Web应用面对大量用户Web服务器需要高效处理并发连接。

比如通过线程池、非阻塞I/O、事件驱动机制如epollWeb服务器可以有效管理成千上万的并发请求确保服务不会因高流量而崩溃或变慢。

理解网络编程通过使用线程池、非阻塞socket、epoll等技术项目可以帮助熟悉Linux下的网络编程模型深入理解如何处理并发连接、如何进行事件驱动的网络通信等核心技术。

实践HTTP协议和Web服务器构建一个能够解析HTTP请求并进行响应的Web服务器有助于理解HTTP协议的工作原理学会如何处理GET和POST请求增强对Web服务端架构的理解。

提升系统优化意识通过进行性能测试和优化例如使用Webbench测试并发性能这个项目还帮助你了解系统性能瓶颈、提升程序的效率、理解并实现高效的并发模型。

线程池相关

构造函数创建线程并启动线程池ThreadPool(size_t

threads)

task;{std::unique_lockstd::mutex

等待任务队列中有任务或者停止信号this-condition.wait(lock,

[this]

std::move(this-tasks.front());this-tasks.pop();}//

执行任务task();}});}}//

std::result_ofF(Args...)::type;//

task

std::make_sharedstd::packaged_taskreturn_type()(std::bind(std::forwardF(f),

std::forwardArgs(args)...));std::futurereturn_type

res

task-get_future();{std::unique_lockstd::mutex

lock(queue_mutex);//

通知一个线程有任务可以执行condition.notify_one();return

res;}//

true;}condition.notify_all();for

(std::thread

等待线程结束}}private:std::vectorstd::thread

workers;

工作线程std::queuestd::functionvoid()

tasks;

线程同步机制用于在多线程环境中协调线程的执行避免数据竞争和资源冲突。

常见的线程同步机制有以下几种

互斥锁Mutex

当多个线程需要安全地修改共享数据时比如线程要同时操作一个变量、写日志、或者修改数据结构。

互斥锁就像一个房间的钥匙只有拿到钥匙的人能进房间修改里面的东西别人必须等他出来并把钥匙还回去。

这种方式确保只有一个线程在修改资源其他线程必须排队。

适合场景

适用于简单的“谁进了房间谁就不能让别人进”的场景比如银行柜台只有一个人能处理事情其他人要排队。

读写锁Read-Write

当多个线程需要读取数据但只有少数线程需要写数据时比如你有一个资源大多数线程只是查看它只有少数线程需要修改它。

读写锁像图书馆多个读者线程可以同时看书读取数据但是一旦有人需要改书写数据其他读者必须等这个人改完再看。

这种机制允许并发读减少锁的开销。

适合场景

适用于“读多写少”的场景比如在线图书馆很多人看书但只有管理员会更新书。

条件变量Condition

适用于某个线程必须等一个条件满足后才能继续工作比如一个线程在等另一个线程完成任务

条件变量就像开会时等老板发言的场景。

线程们在“会议室”里等条件满足比如任务队列有新任务一旦条件满足了其他线程被通知并开始工作。

适合场景

用于生产者-消费者模型比如有一个任务队列消费者线程只有在有新任务时才能干活。

信号量Semaphore

控制资源的访问数量比如限制某个资源同时只能有固定数量的线程使用比如数据库连接池。

信号量就像停车场的闸机只允许有限数量的车线程进入。

停车场满了其他车只能在外面等。

有时可以允许多个线程同时访问但有上限。

适合场景

适用于控制资源访问数量的场景比如一个数据库有5个连接池你只允许最多5个线程同时连接数据库。

自旋锁Spinlock

自旋锁像排队等公交车如果你知道车马上就到你可能就会站着等而不会坐下休息线程不会睡眠而是不断检查锁是否可用。

它适用于等待时间非常短的场景因为忙等很浪费资源。

适合场景

适合非常短时间的临界区适合多核处理器上多个线程竞争时开销低于传统的互斥锁。

每种机制都有特定的使用场景和特点合理选择可以避免资源争用和死锁确保程序高效运行。

在run函数中我们为了能够处理高并发的问题将线程池中的工作线程都设置为阻塞等待在请求队列是否不为空的条件上因此项目中线程池中的工作线程是处于

一直阻塞等待

当处理完任务后如果请求队列为空时则这个线程重新回到阻塞等待的状态

当处理完任务后如果请求队列不为空时那么这个线程将处于与其他线程竞争资源的状态谁获得锁谁就获得了处理事件的资格。

如果同时1000个客户端进行访问请求线程数不多怎么能及时响应处理每一个呢

首先在创建线程的同时就调用了pthread_detach将线程进行分离不用单独对工作线程进行回收资源自动回收。

我们通过子线程的run调用函数进行while循环让每一个线程池中的线程永远都不会停止访问请求被封装到请求队列(list)中如果没有任务线程就一直阻塞等待有任务线程就抢占式进行处理直到请求队列为空表示任务全部处理完成。

除此之外该项目采用了I/O多路复用技术当客户连接有事件需要处理时epoll会进行事件提醒然后将对应的任务加入请求队列等待工作线程的竞争不仅如此

如果一个客户请求需要占用线程很久的时间会不会影响接下来的客户请求呢有什么好的策略呢?

会因为线程池内线程的数量时有限的如果客户请求占用线程时间过久的话会影响到处理请求的效率当请求处理过慢时会造成后续接受的请求只能在请求队列中等待被处理从而影响接下来的客户请求。

应对策略(定时器)

超过时间先发送信号告知线程处理超时然后设定一个时间间隔再次检测若此时这个请求还占用线程则直接将其断开连接。

虚假唤醒指的是某个线程被错误地唤醒而实际上没有任何满足它被唤醒的条件。

这种现象常常发生在使用条件变量来实现线程同步时。

2号线程也想从队列中获取一个元素但此时队列为空2号线程便只能进入阻塞(cond.wait())等待队列非空。

这时3号线程将一个元素入队并调用cond.notify()唤醒条件变量。

处于等待状态的2号线程接收到3号线程的唤醒信号便准备解除阻塞状态执行接下来的任务(获取队列中的元素)。

然而可能出现这样的情况当2号线程准备获得队列的锁去获取队列中的元素时此时1号线程刚好执行完之前的元素操作返回再去请求队列中的元素1号线程便获得队列的锁检查到队列非空就获取到了3号线程刚刚入队的元素然后释放队列锁。

等到2号线程获得队列锁判断发现队列仍为空1号线程“偷走了”这个元素所以对于2号线程而言这次唤醒就是“虚假”的它需要再次等待队列非空。

如何避免虚假唤醒?

为了防止这种情况通常的做法是在等待条件变量时使用一个条件循环来重新检查唤醒条件。

这种结构通常如下

std::queueint

重新检查条件是否满足。

如果条件不满足消费者将继续等待直到条件真正满足即队列中有任务。

这种额外的条件检查可以避免虚假唤醒带来的问题确保线程在正确的条件下执行。

总结来说在多线程环境中虚假唤醒是正常现象但通过在唤醒后重新检查条件的方式程序可以有效防止虚假唤醒导致的逻辑错误。

10.

2、通过Thread类中成员方法interrupt()主动退出(发送中断信号)

11.

1当调用join()主线程等待子线程执行完之后主线程才可以继续执行此时主线程会释放掉执行完后的子线程资源。

主线程等待子线程执行完可能会造成性能损失。

2当调用detach()主线程与子线程分离他们成为了两个独立的线程遵循cpu的时间片调度分配策略。

子线程执行完成后会自己释放掉资源。

分离后的线程主线程将对它没有控制权。

当你确定程序没有使用共享变量或引用之类的话可以使用detch函数分离线程。

12.

Ncpu。

因为线程间竞争的不是CPU的计算资源而是IOIO的处理一般较慢多于cores数的线程将为CPU争取更多的任务不至在线程处理IO的过程造成CPU空闲导致资源浪费

最佳线程数量

由公式可得线程等待时间所占比例越高需要越多的线程线程CPU时间所占比例越高所需的线程数越少。

12.

随着线程数越多效率越来越高但到一个峰值再增加线程数量时就会出现问题。

线程太多要来回的切换最终可能线程切换所用时间比执行时间业务所用时间还大。

并发模型相关

2.reactor、proactor、主从reactor模型的区别

3.你用了epoll说一下为什么用epoll还有其他复用方式吗区别是什么

4.介绍一下几种I/O模型

操作时会被阻塞直到操作完成。

例如当应用程序请求从磁盘读取数据时如果数据不可用程序将会在调用处停止执行直到数据被读取完成。

这种模型简单但效率较低因为在等待

I/O

EAGAIN应用程序可以继续执行其他任务。

应用程序需要不断地查询

I/O

流就绪即数据可读或可写时应用程序会被唤醒以处理该事件。

这种模型适合处理大量并发连接因为单个线程可以管理多个网络连接。

信号驱动

流就绪时操作系统会发送一个信号通知应用程序。

然后应用程序可以启动

I/O

操作完成后会收到一个通知。

这种模型最大化了程序的运行效率因为应用程序无需在任何点等待

I/O

提供了更高的性能和灵活性特别适合于网络服务和高并发应用。

选择合适的

I/O

5.简单说一下服务器使用的并发模型两种高效的事件并发处理模式reactor、proactor主从reactor模型

事件I/O事件、信号及定时事件

1reactor模式中主线程(I/O处理单元)只负责监听文件描述符上是否有事件发生有的话立即通知工作线程(逻辑单元

)将socket可读写事件放入请求队列交给工作线程处理即读写数据、接受新连接及处理客户请求均在工作线程中完成。

通常由同步I/O实现epoll_wait。

2proactor模式中主线程和内核负责处理读写数据、接受新连接等I/O操作工作线程仅负责业务逻辑如处理客户请求。

通常由异步I/O实现(aio_read/aio_write)。

由于异步I/O并不成熟实际中使用较少本服务器采用同步I/O模拟Proactor模式

当socket上有数据可读epoll_wait通知主线程,主线程从socket循环读取数据直到没有更多数据可读然后将读取到的数据封装成一个请求对象并插入请求队列。

睡眠在请求队列上某个工作线程被唤醒它获得请求对象并处理客户请求然后往epoll内核事件表中注册该socket上的写就绪事件

当socket上有数据可写epoll_wait通知主线程。

主线程往socket上写入服务器处理客户请求的结果。

主从Reactor模式核心思想是主反应堆线程只负责分发Acceptor连接建立已连接套接字上的I/O事件交给sub-reactor负责分发。

其中

主反应堆线程一直在感知连接建立的事件如果有连接成功建立主反应堆线程通过accept方法获取已连接套接字接下来会按照一定的算法选取一个从反应堆线程并把已连接套接字加入到选择好的从反应堆线程中。

主反应堆线程唯一的工作就是调用accept获取已连接套接字以及将已连接套接字加入到从反应堆线程中。