中扶建设网站,做sns网站要多大空间,请人做网站要,网站改了关键词TinyWebSever项目面试题整理
1.为什么要做这样一个项目#xff1f; 满足高并发和高性能需求#xff1a;现代Web应用面对大量用户#xff0c;Web服务器需要高效处理并发连接。比如通过线程池、非阻塞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测试并发性能这个项目还帮助你了解系统性能瓶颈、提升程序的效率、理解并实现高效的并发模型。
线程池相关
2.手写一下线程池
#include iostream
#include vector
#include queue
#include thread
#include mutex
#include condition_variable
#include functional
#include future
#include atomicclass ThreadPool {
public:// 构造函数创建线程并启动线程池ThreadPool(size_t threads) : stop(false) {for (size_t i 0; i threads; i) {workers.emplace_back([this] {while (true) {std::functionvoid() task;{std::unique_lockstd::mutex lock(this-queue_mutex);// 等待任务队列中有任务或者停止信号this-condition.wait(lock, [this] {return this-stop || !this-tasks.empty();});if (this-stop this-tasks.empty()) {return; // 线程退出}// 从任务队列中取出一个任务task std::move(this-tasks.front());this-tasks.pop();}// 执行任务task();}});}}// 向线程池添加新任务template class F, class... Argsauto enqueue(F f, Args... args) - std::futuretypename std::result_ofF(Args...)::type {using return_type typename std::result_ofF(Args...)::type;// 打包任务保存到shared_ptr中auto 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);// 禁止在停止线程池后添加任务if (stop) {throw std::runtime_error(enqueue on stopped ThreadPool);}// 将任务添加到队列tasks.emplace([task]() { (*task)(); });}// 通知一个线程有任务可以执行condition.notify_one();return res;}// 析构函数等待所有线程完成任务后关闭~ThreadPool() {{std::unique_lockstd::mutex lock(queue_mutex);stop true;}condition.notify_all();for (std::thread worker : workers) {worker.join(); // 等待线程结束}}private:std::vectorstd::thread workers; // 工作线程std::queuestd::functionvoid() tasks; // 任务队列std::mutex queue_mutex; // 任务队列互斥锁std::condition_variable condition; // 条件变量用于任务调度std::atomicbool stop; // 停止标志
};int main() {// 创建一个线程池包含4个工作线程ThreadPool pool(4);// 向线程池添加一些任务并获取结果auto result1 pool.enqueue([] { return Hello, ; });auto result2 pool.enqueue([](const std::string name) { return name World!; }, C );// 输出任务结果std::cout result1.get() result2.get() std::endl;return 0;
}
3. 线程的同步机制有哪些
线程同步机制用于在多线程环境中协调线程的执行避免数据竞争和资源冲突。常见的线程同步机制有以下几种
1. 互斥锁Mutex
场景 当多个线程需要安全地修改共享数据时比如线程要同时操作一个变量、写日志、或者修改数据结构。
特点 互斥锁就像一个房间的钥匙只有拿到钥匙的人能进房间修改里面的东西别人必须等他出来并把钥匙还回去。这种方式确保只有一个线程在修改资源其他线程必须排队。
适合场景 适用于简单的“谁进了房间谁就不能让别人进”的场景比如银行柜台只有一个人能处理事情其他人要排队。
2. 读写锁Read-Write Lock
场景 当多个线程需要读取数据但只有少数线程需要写数据时比如你有一个资源大多数线程只是查看它只有少数线程需要修改它。
特点 读写锁像图书馆多个读者线程可以同时看书读取数据但是一旦有人需要改书写数据其他读者必须等这个人改完再看。这种机制允许并发读减少锁的开销。 写者优先于读者一旦有写者则后续读者必须等待唤醒时优先考虑写者
适合场景 适用于“读多写少”的场景比如在线图书馆很多人看书但只有管理员会更新书。
3. 条件变量Condition Variable
场景 适用于某个线程必须等一个条件满足后才能继续工作比如一个线程在等另一个线程完成任务 。 特点 条件变量就像开会时等老板发言的场景。线程们在“会议室”里等条件满足比如任务队列有新任务一旦条件满足了其他线程被通知并开始工作。
适合场景 用于生产者-消费者模型比如有一个任务队列消费者线程只有在有新任务时才能干活。
4. 信号量Semaphore
场景 控制资源的访问数量比如限制某个资源同时只能有固定数量的线程使用比如数据库连接池。
特点 信号量就像停车场的闸机只允许有限数量的车线程进入。停车场满了其他车只能在外面等。有时可以允许多个线程同时访问但有上限。
适合场景 适用于控制资源访问数量的场景比如一个数据库有5个连接池你只允许最多5个线程同时连接数据库。
5. 自旋锁Spinlock
场景 当锁的等待时间非常短时比如线程很快就能拿到锁的情况。
特点 自旋锁像排队等公交车如果你知道车马上就到你可能就会站着等而不会坐下休息线程不会睡眠而是不断检查锁是否可用。它适用于等待时间非常短的场景因为忙等很浪费资源。
适合场景 适合非常短时间的临界区适合多核处理器上多个线程竞争时开销低于传统的互斥锁。 每种机制都有特定的使用场景和特点合理选择可以避免资源争用和死锁确保程序高效运行。
4. 线程池中的工作线程是一直等待吗
在run函数中我们为了能够处理高并发的问题将线程池中的工作线程都设置为阻塞等待在请求队列是否不为空的条件上因此项目中线程池中的工作线程是处于 一直阻塞等待 的模式下的。
5. 你的线程池工作线程处理完一个任务后的状态是什么
1 当处理完任务后如果请求队列为空时则这个线程重新回到阻塞等待的状态
2 当处理完任务后如果请求队列不为空时那么这个线程将处于与其他线程竞争资源的状态谁获得锁谁就获得了处理事件的资格。
6. 如果同时1000个客户端进行访问请求线程数不多怎么能及时响应处理每一个呢
本项目是通过对子线程循环调用来解决高并发的问题的。
首先在创建线程的同时就调用了pthread_detach将线程进行分离不用单独对工作线程进行回收资源自动回收。
我们通过子线程的run调用函数进行while循环让每一个线程池中的线程永远都不会停止访问请求被封装到请求队列(list)中如果没有任务线程就一直阻塞等待有任务线程就抢占式进行处理直到请求队列为空表示任务全部处理完成。 除此之外该项目采用了I/O多路复用技术当客户连接有事件需要处理时epoll会进行事件提醒然后将对应的任务加入请求队列等待工作线程的竞争不仅如此 epoll的et水平触发模式可以及时的处理每一个线程的请求。
7. 如果一个客户请求需要占用线程很久的时间会不会影响接下来的客户请求呢有什么好的策略呢?
会因为线程池内线程的数量时有限的如果客户请求占用线程时间过久的话会影响到处理请求的效率当请求处理过慢时会造成后续接受的请求只能在请求队列中等待被处理从而影响接下来的客户请求。
应对策略(定时器)
我们可以为线程处理请求对象设置处理超时时间, 超过时间先发送信号告知线程处理超时然后设定一个时间间隔再次检测若此时这个请求还占用线程则直接将其断开连接。
8. 什么是虚假唤醒?
虚假唤醒指的是某个线程被错误地唤醒而实际上没有任何满足它被唤醒的条件。这种现象常常发生在使用条件变量来实现线程同步时。 举个例子我们现在有一个生产者-消费者队列和三个线程。
1 1号线程从队列中获取了一个元素此时队列变为空。
2 2号线程也想从队列中获取一个元素但此时队列为空2号线程便只能进入阻塞(cond.wait())等待队列非空。
3 这时3号线程将一个元素入队并调用cond.notify()唤醒条件变量。
4 处于等待状态的2号线程接收到3号线程的唤醒信号便准备解除阻塞状态执行接下来的任务(获取队列中的元素)。
5 然而可能出现这样的情况当2号线程准备获得队列的锁去获取队列中的元素时此时1号线程刚好执行完之前的元素操作返回再去请求队列中的元素1号线程便获得队列的锁检查到队列非空就获取到了3号线程刚刚入队的元素然后释放队列锁。
6 等到2号线程获得队列锁判断发现队列仍为空1号线程“偷走了”这个元素所以对于2号线程而言这次唤醒就是“虚假”的它需要再次等待队列非空。
9. 如何避免虚假唤醒?
为了防止这种情况通常的做法是在等待条件变量时使用一个条件循环来重新检查唤醒条件。这种结构通常如下
std::queueint queue;
std::mutex mtx;
std::condition_variable cv;void consumer() {std::unique_lockstd::mutex lock(mtx);while (queue.empty()) {cv.wait(lock); // 等待被唤醒}// 唤醒后再检查队列是否为空避免虚假唤醒造成的误操作int task queue.front();queue.pop();// 处理任务
}void producer() {std::unique_lockstd::mutex lock(mtx);queue.push(1); // 向队列中添加任务cv.notify_one(); // 通知消费者线程
}解释
当消费者被唤醒时不是立即执行任务而是先通过 while(queue.empty()) 重新检查条件是否满足。如果条件不满足消费者将继续等待直到条件真正满足即队列中有任务。这种额外的条件检查可以避免虚假唤醒带来的问题确保线程在正确的条件下执行。
总结来说在多线程环境中虚假唤醒是正常现象但通过在唤醒后重新检查条件的方式程序可以有效防止虚假唤醒导致的逻辑错误。
10. 如何销毁线程?
1、通过判断标志位主动退出(比如出现超时和报错) 2、通过Thread类中成员方法interrupt()主动退出(发送中断信号) 3、通过Thread类中成员方法stop()强行退出
11. detach和join有什么区别?
1当调用join()主线程等待子线程执行完之后主线程才可以继续执行此时主线程会释放掉执行完后的子线程资源。主线程等待子线程执行完可能会造成性能损失。
2当调用detach()主线程与子线程分离他们成为了两个独立的线程遵循cpu的时间片调度分配策略。子线程执行完成后会自己释放掉资源。分离后的线程主线程将对它没有控制权。
当你确定程序没有使用共享变量或引用之类的话可以使用detch函数分离线程。
12. 线程池中有多少个线程线程池数量如何设定
默认8个
调整线程池中的线程数量的最主要的目的是为了充分并合理地使用 CPU 和内存等资源从而最大限度地提高程序的性能。
Ncpu 表示 CPU的数量。
如果是CPU密集型任务就需要尽量压榨CPU参考值可以设为 Ncpu1能够实现最优的CPU 利用率1 是保证当线程由于页缺失故障操作系统或其它原因 导致暂停时额外的这个线程就能顶上去保证CPU 时钟周期不被浪费
如果是IO密集型任务参考值可以设置为 2 * Ncpu。因为线程间竞争的不是CPU的计算资源而是IOIO的处理一般较慢多于cores数的线程将为CPU争取更多的任务不至在线程处理IO的过程造成CPU空闲导致资源浪费
最佳线程数量 线程等待时间线程CPU时间 线程CPU时间* CPU个数。
由公式可得线程等待时间所占比例越高需要越多的线程线程CPU时间所占比例越高所需的线程数越少。
12. 线程越多越好么
随着线程数越多效率越来越高但到一个峰值再增加线程数量时就会出现问题。线程太多要来回的切换最终可能线程切换所用时间比执行时间业务所用时间还大。
并发模型相关
1.简单说一下服务器使用的并发模型
2.reactor、proactor、主从reactor模型的区别
3.你用了epoll说一下为什么用epoll还有其他复用方式吗区别是什么
4.介绍一下几种I/O模型
下面是几种常见的 I/O 模型
1. 阻塞 I/OBlocking I/O
在阻塞 I/O 模型中应用程序执行 I/O 操作时会被阻塞直到操作完成。例如当应用程序请求从磁盘读取数据时如果数据不可用程序将会在调用处停止执行直到数据被读取完成。这种模型简单但效率较低因为在等待 I/O 操作完成期间程序不能执行其他任务。
2. 非阻塞 I/ONon-blocking I/O
在非阻塞 I/O 模型中应用程序执行 I/O 操作时不会被阻塞。如果 I/O 操作不能立即完成如数据未就绪操作会立即返回一个错误通常是 EWOULDBLOCK 或 EAGAIN应用程序可以继续执行其他任务。应用程序需要不断地查询 I/O 操作是否完成这种方式称为轮询。
3. I/O 多路复用I/O Multiplexing
I/O 多路复用允许应用程序同时监控多个 I/O 流的事件。常用的实现有 select、poll 和 epoll仅在 Linux 上。应用程序使用这些调用等待多个 I/O 流中的任何一个变为就绪状态。当 I/O 流就绪即数据可读或可写时应用程序会被唤醒以处理该事件。这种模型适合处理大量并发连接因为单个线程可以管理多个网络连接。
4. 信号驱动 I/OSignal-driven I/O
在信号驱动 I/O 模型中应用程序首先对一个 I/O 流进行信号处理配置然后继续执行其他任务当 I/O 流就绪时操作系统会发送一个信号通知应用程序。然后应用程序可以启动 I/O 操作来处理数据。这种模型允许应用程序异步地处理 I/O 事件但并不广泛使用。
5. 异步 I/OAsynchronous I/O
异步 I/O 模型是最高效的一种应用程序发起 I/O 操作后可以立即继续执行其他任务。与信号驱动 I/O 不同异步 I/O 的操作系统不仅通知应用程序 I/O 流就绪而且会自动完成数据的传输。应用程序在 I/O 操作完成后会收到一个通知。这种模型最大化了程序的运行效率因为应用程序无需在任何点等待 I/O 操作完成。
总结
这些 I/O 模型各有特点适用于不同的应用场景。阻塞和非阻塞 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模式
同步I/O模型的工作流程如下epoll_wait为例
主线程往epoll内核事件表注册socket上的读就绪事件。
主线程调用epoll_wait等待socket上有数据可读
当socket上有数据可读epoll_wait通知主线程,主线程从socket循环读取数据直到没有更多数据可读然后将读取到的数据封装成一个请求对象并插入请求队列。
睡眠在请求队列上某个工作线程被唤醒它获得请求对象并处理客户请求然后往epoll内核事件表中注册该socket上的写就绪事件
主线程调用epoll_wait等待socket可写。
当socket上有数据可写epoll_wait通知主线程。主线程往socket上写入服务器处理客户请求的结果。
3 主从Reactor模式核心思想是主反应堆线程只负责分发Acceptor连接建立已连接套接字上的I/O事件交给sub-reactor负责分发。其中 sub-reactor的数量可以根据CPU的核数来灵活设置。
主反应堆线程一直在感知连接建立的事件如果有连接成功建立主反应堆线程通过accept方法获取已连接套接字接下来会按照一定的算法选取一个从反应堆线程并把已连接套接字加入到选择好的从反应堆线程中。主反应堆线程唯一的工作就是调用accept获取已连接套接字以及将已连接套接字加入到从反应堆线程中。
