春招面试高频题目总结
面试问题
-
redis 可以用于进程间通信吗？ Why？How? ---> 延展一下 有哪些进程间通信技术, 优劣如何？
-
有大量的插入sql语句，一条条的插入性能很差，如何通过事务进行优化？
-
保证线程安全的策略有哪些？
-
你知道哪些设计模式？ 有什么理解？ 单例、工厂方法、责任链、模板方法、策略模式 都是基类抽象固定方法。子类提供具体实现。
-
如何实现服务端与客户端的即时通讯？
-
消息队列如何保证这个消息一定执行？ 不会丢失？ 持久化
-
消息队列用途有哪些？ 削峰，解耦，异步
-
多线程场景下有哪些死锁的具体案例？如何避免？如何定位死锁的位置?
-
如果让你来设计实现事务你觉得应该如何实现？
-
C++11常用新特性有哪些？
-
MySQL表比较大的情况下，怎么优化查询?
-
滑动窗口的大小限制因素有哪些？ 网络环境、网络带宽、对方接收缓冲区大小
-
STL中有哪些常见的容器？map和unordered_map的异同
-
有哪些的负载均衡算法？ 轮询、加权轮询、ip_hash映射
-
乐观锁，悲观锁
-
无锁原子操作和加锁操作都是用于实现线程安全的并发控制机制，它们各有优缺点
-
三次握手的过程描述
-
select、poll、epoll 这块？ select、poll适合比较活跃的IO事件比较多的场景下，epoll适合活跃的IO事件没那么多的场景下
redis 可以用于进程间通信吗？ Why？How? ---> 延展一下 有哪些进程间通信技术, 优劣如何？
可以，因为它除了可以做高速缓存以外，还可以提供发布订阅机制。来支持进程间通信。
除了redis，还有消息中间件也可以进行进程间通信，异步通信机制。
还要答出来共享内存是最快的进程间通信技术，因为它避免了大量数据的拷贝。（但是存在多进程并发访问共享内存的同步互斥问题。结合PV操作）PV操作可能出现死锁。怎么解决死锁的问题，如何避免死锁，定位死锁。
管道（Pipe）：
-
优点：
-
简单易用，适用于父子进程之间的通信。
-
实现简单，只需使用系统调用即可。
-
-
缺点：
-
只能用于具有亲缘关系的进程间通信。
-
数据流是单向的，需要建立双向通信时需要创建两个管道。
-
只能在具有公共祖先的进程间通信。
-
命名管道（Named Pipe，FIFO）：
-
优点：
-
可用于非亲缘关系进程间的通信。
-
允许多个进程通过命名管道进行通信。
-
-
缺点：
-
仍然是单向通信。
-
缓冲区有限，可能会出现阻塞。
-
消息队列（Message Queues）：
-
优点：
-
支持异步通信，发送者和接收者之间无需同步。
-
可以通过消息队列传输多种数据类型。
-
允许多个进程同时读写队列。
-
-
缺点：
-
数据复制开销较大。
-
消息队列的长度有限，可能会造成阻塞或丢失消息。
-
信号量（Semaphores）：
-
优点：
-
可以用于控制对共享资源的访问。
-
支持同步和互斥。
-
-
缺点：
-
容易出现死锁和竞争条件。
-
不提供直接的数据传输，仅用于同步。
-
共享内存（Shared Memory）：
-
优点：
-
数据直接在进程间共享，效率高。
-
不需要数据的复制，减少了开销。
-
适用于大量数据的交换。
-
-
缺点：
-
需要进行显式的同步。
-
需要处理数据一致性和互斥访问问题。
-
套接字（Sockets）：
-
优点：
-
跨网络进程间通信。
-
可以实现不同主机之间的通信。
-
-
缺点：
-
实现复杂度较高。
-
需要考虑网络延迟和丢包等问题。
-
不同的IPC技术适用于不同的场景和需求。选择合适的IPC技术需要考虑通信的性质、进程间关系、数据量大小、性能需求以及安全性等因素。
有大量的插入sql语句，一条条的插入性能很差，如何通过事务进行优化？ （一定要问清楚，数据库类型，主机配置情况（几个处理器及核心）等等。将场景具体化再回答。） 在处理大量的插入 SQL 语句时，确保在一个事务中执行并提升性能的方法有几种：
-
使用批量插入：将多个插入语句合并成一个较大的插入语句，减少通信开销（客户端跟数据库服务端之间的通信开销）和 事务开销。例如，在 MySQL 中可以使用
INSERT INTO ... VALUES (v1), (v2), ...的语法来一次性插入多行数据。 -
关闭自动提交：在开始插入之前，将数据库连接的自动提交模式关闭，在完成所有插入操作后手动提交事务。这样可以减少事务的开销，因为每次插入都会导致一次提交。
-
合理设置事务大小：不要让事务过于庞大，因为过大的事务可能会导致锁定表或者内存不足。可以根据系统负载和性能测试结果来确定一个合适的事务大小。
-
适当优化数据库配置：根据数据库类型和实际情况，调整数据库配置参数以优化插入性能，比如调整数据库的缓冲池大小、日志配置等。
-
利用并行处理：将大量的插入任务拆分成多个子任务，并行执行，可以充分利用系统资源（多核），提高插入速度。
-
优化索引和约束：在执行大量插入操作之前，考虑是否需要暂时禁用索引和约束，以减少插入操作的开销，插入完成后再重新启用索引和约束。
综上所述，通过合理的批量插入、事务管理、并行处理等方法，可以有效提升大量插入 SQL 语句的性能，并保证在一个事务中执行。
保证线程安全的策略有哪些？
保证线程安全的策略有多种，常见的包括：
-
加锁机制： 使用互斥锁、读写锁、自旋锁等锁机制来保护共享资源，在访问共享资源时先获取锁，操作完成后释放锁，确保同一时刻只有一个线程访问共享资源。
-
原子操作： 使用原子操作来保证某些操作的原子性，例如原子整型、原子指针等，可以避免多线程并发访问时出现的数据竞争问题。
-
线程局部存储（TLS）： 将每个线程独享的数据存储在线程局部存储中，避免多个线程共享同一份数据而引发的线程安全问题。
-
不可变对象： 设计不可变对象，即对象创建后不能被修改，可以避免多线程并发访问时的竞态条件。
-
并发数据结构： 使用专门设计的并发数据结构，如并发队列、并发哈希表等，内部实现采用加锁或原子操作来保证线程安全。
-
事务性内存操作： 使用事务性内存操作（Transactional Memory）来保证一系列操作的原子性，避免加锁导致的性能开销。
-
信号量和条件变量： 使用信号量和条件变量等同步原语来控制线程之间的同步和通信，确保共享资源的正确访问顺序。
-
内存屏障（Memory Barrier）： 使用内存屏障来保证内存操作的顺序性和一致性，避免出现内存乱序访问导致的线程安全问题。
你知道哪些设计模式？ 有什么理解？ 单例、工厂方法（抽象工厂）、责任链、模板方法、策略模式 都是基类抽象固定方法。子类提供具体实现。
-
设计模式是一种规范，一种代码实现上的共识。设计模式都是遵循设计原则的。是站在长远和实用性两者的综合之上的设计方案。现有的设计模式可以给我们一个快速实现的代码原型，结构。不停的迭代其实是设计原则的体现。迭代的过程其实更像是设计出更优雅的代码，更符合设计原则的代码。
-
常见的设计原则： 迪米特法则（尽可能少了解别的类的实现），依赖倒置原则（高层模块不依赖于底层模块，两者都依赖于抽象。尽可能的利用抽象层隔离对具体对象的依赖），开闭原则（一个类应该对扩展开放，对修改关闭），组合优于继承，里氏替换（子类必须完成父类的职责），单例职责原则（一个类尽可能只有单一的一个变化点，只有一个引起它变化的原因）。
-
不论多少设计原则，其本质都是为了更好的高内聚低耦合。封装稳定的抽象层。隔离可扩展的变化到具体的类实现中。
-
单例：因为全局仅仅一个对象，所以我们需要限制它的构造以及它属于整个类的归属（static）。其次，多线程环境下的单例，我们需要保障线程安全的问题（双检锁，call_once，atomic_function with atomic_objection 结合 内存栅栏保证指令顺序执行，C++11之后的static实现）。
-
工厂方法：只提供创建接口，隔离内部实现，方便用户使用。
-
责任链：一层一层的处理。处理结束打断返回结果。整个链走完，无法处理则无法处理。
-
模板方法：基类提供执行的流程模板，执行流程中的具体步骤实现延迟到子类。
-
策略模式：基类提供抽象的策略接口。不同的子类进行具体实现。
如何实现服务端与客户端的即时通讯？
-
长连接+消息队列（比较常见的思路)
长连接和消息队列结合实现即时通讯是一种常见的方案，主要通过以下步骤实现：
-
建立长连接：
-
客户端与服务端建立长连接，通常使用WebSocket等技术来实现。长连接的建立使得客户端和服务端之间可以保持持久的通信连接，而不需要每次通信都建立新的连接。
-
-
消息队列的使用：
-
服务端使用消息队列作为消息的中转站，客户端发送的消息首先存储到消息队列中，然后服务端从消息队列中获取消息并推送给目标客户端。
-
-
客户端发送消息：
-
客户端通过长连接将消息发送到服务端指定的接口。
-
服务端接收到客户端发送的消息后，将消息存储到消息队列中。
-
-
服务端推送消息：
-
服务端定期或者实时地从消息队列中获取消息，并将消息推送给目标客户端。
-
可以使用轮询、长轮询、WebSockets等方式向客户端推送消息。
-
-
消息处理和转发：
-
服务端从消息队列中获取消息后，进行消息处理和转发，确保消息被发送到目标客户端。
-
可以根据消息的内容和目标客户端的标识符来确定消息的发送目标。
-
-
消息确认和处理：
-
客户端接收到服务端推送的消息后进行处理，并向服务端发送确认消息。
-
服务端接收到客户端的确认消息后，可以进行相应的处理，如删除已发送的消息或者记录消息的发送状态。
-
通过长连接和消息队列的结合实现即时通讯，可以有效地提高通讯的效率和可靠性，确保消息的实时性和稳定性。同时，还可以通过消息队列来实现消息的异步处理和解耦，提高系统的扩展性和可维护性。
即时通讯技术通常用于实现聊天室应用时，可以看作是一种发布订阅（Pub/Sub）模式的应用：
-
消息发布：
-
在聊天室应用中，客户端发送的消息相当于发布了消息，这些消息需要被传递给其他在线用户。
-
在发布订阅模式中，发布者发布消息到消息队列或者主题，消息随后被传递给所有已订阅该主题的订阅者。
-
-
消息订阅：
-
在聊天室应用中，其他在线用户需要订阅接收其他用户发送的消息，以便实时地看到聊天内容。
-
在发布订阅模式中，订阅者订阅感兴趣的主题，以便接收相关的消息。
-
-
消息传递：
-
聊天室应用中，服务端将客户端发送的消息传递给其他在线用户。
-
在发布订阅模式中，消息队列或者发布者负责将消息传递给所有订阅者。
-
-
实时性和即时性：
-
聊天室应用中的消息需要实时地传递给其他在线用户，以保证即时通讯的效果。
-
发布订阅模式中的消息也可以实现实时性，使得订阅者能够即时地收到新发布的消息。
-
因此，可以说聊天室应用中的即时通讯技术与发布订阅模式具有相似的机制和特点，都是为了实现消息的发布和订阅，以实现实时通讯的目的。使用发布订阅模式可以使得聊天室应用的架构更加灵活、可扩展，同时也能够提高通讯的实时性和可靠性。
多线程场景下有哪些死锁的具体案例？如何避免？如何定位死锁的位置?
在多线程编程场景下，死锁是一种常见的并发问题，它会导致线程相互等待对方释放资源而无法继续执行，造成程序的假死状态。以下是一些常见的死锁现象和导致死锁的情况：
-
互斥锁的交叉等待：多个线程分别持有某些资源，并尝试获取其他线程持有的资源，从而造成循环等待。
-
资源不足的等待：多个线程同时占用了一些资源，并且等待其他线程释放它们持有的资源，但由于资源不足导致无法继续执行。
-
死锁链：多个线程依次等待对方释放资源，形成了一个闭合的环路，导致所有线程都无法继续执行。
为了避免死锁，可以采取以下一些措施：
-
避免使用多个锁：尽可能设计线程安全的数据结构和算法，避免使用多个锁来保护数据，减少死锁的可能性。
-
按固定顺序获取锁：确保所有线程获取锁的顺序是一致的，从而避免死锁链的发生。
-
使用超时机制：在获取锁的操作中使用超时机制，避免线程长时间等待锁资源而无法继续执行。
-
避免嵌套锁：尽量避免在持有一个锁的同时尝试获取其他锁，以减少死锁的可能性。
-
使用锁层次：为每个锁分配一个唯一的层次号，线程在获取多个锁时按照层次号的顺序获取锁，从而避免死锁的发生。
-
使用锁粒度调整：适当调整锁的粒度，将锁粒度尽量减小，以降低线程之间竞争锁的频率，减少死锁的可能性。
-
使用锁协议：定义一套锁协议，明确线程获取锁和释放锁的规则，以避免死锁的发生。
通过以上措施可以有效地避免多线程编程中的死锁问题，保证程序的稳定性和可靠性。
如果让你来设计实现事务你觉得应该如何实现？
设计事务的实现需要考虑到事务的ACID特性（原子性、一致性、隔离性和持久性），以及并发控制、日志记录和回滚等方面。以下是一个基本的事务实现设计：
-
事务管理器：
-
实现事务的开始、提交和回滚等操作。
-
维护事务的状态信息，如事务的开始时间、提交时间等。
-
-
并发控制：
-
使用锁机制保证事务的隔离性，防止并发执行中的数据竞争和不一致性。
-
使用事务隔离级别（如读未提交、读已提交、可重复读、串行化）来控制不同事务之间的可见性和影响范围。
-
-
日志记录：
-
实现事务日志的记录，包括事务开始、提交、回滚等操作，以及对数据的修改操作。
-
采用写前日志或者写后日志的方式，保证数据的持久性和原子性。
-
-
回滚和恢复：
-
提供事务回滚的功能，当事务执行失败或者被中断时，撤销事务对数据的修改，将数据库恢复到事务开始前的状态。
-
利用事务日志实现崩溃恢复机制，根据日志记录的信息进行数据恢复。
-
-
锁管理：
-
管理事务执行期间所涉及的锁，包括共享锁和排他锁。
-
通过锁的粒度控制来减小锁的竞争范围，提高并发性能。
-
-
事务的原子性和一致性：
-
保证事务的原子性，即事务中的操作要么全部执行成功，要么全部不执行。
-
保证事务的一致性，即事务执行前后数据库的状态保持一致。
-
-
持久性：
-
确保事务的提交后，对数据的修改能够持久保存到存储介质中，以防止数据丢失。
-
-
性能优化：
-
通过合理的事务设计和并发控制机制，优化事务的性能和吞吐量。
-
以上是一个基本的事务实现设计框架，具体的实现需要根据具体的应用场景和数据库系统的特性进行调整和优化。
MySQL表比较大的情况下，怎么优化查询?
在处理MySQL表比较大的情况下，可以采取一系列优化查询的策略来提高查询性能和效率。以下是一些常见的优化查询的方法：
-
索引优化：
-
确保表上的列有适当的索引，尤其是经常用于查询和筛选的列。
-
使用覆盖索引（Covering Index）来减少查询所需的IO操作。
-
避免在索引列上进行函数操作，以充分利用索引。
-
-
查询优化：
-
避免使用SELECT *，而是明确列出需要的列，减少不必要的数据传输。
-
使用JOIN替代子查询，尽可能避免使用复杂的嵌套查询。
-
对于复杂的查询，考虑将查询结果缓存到缓存表或者使用临时表。
-
-
分页查询优化：
-
使用LIMIT和OFFSET限制返回的记录数量，避免一次性返回过多的数据。
-
使用游标进行分页查询，避免在大表上使用OFFSET造成的性能问题。
-
-
数据结构优化：
-
使用合适的数据类型来存储数据，尽量避免使用过大的数据类型。
-
对于经常需要更新的表，考虑使用InnoDB引擎，以支持行级锁和事务。
-
-
查询缓存：
-
启用MySQL的查询缓存功能，对于相同的查询结果可以直接从缓存中获取，减少数据库的访问量。
-
注意查询缓存对于更新频繁的表可能不适用，会造成缓存命中率下降。
-
-
分区表：
-
将大表按照某个列进行分区，可以提高查询的效率，尤其是在查询特定分区时。
-
考虑根据数据的特点选择合适的分区策略，如范围分区、哈希分区等。
-
-
查询重构：
-
对于复杂的查询，考虑将其拆分成多个简单的查询，然后在应用层进行数据整合和处理。
-
考虑使用存储过程或者触发器来实现一些复杂的查询逻辑。
-
通过以上优化查询的方法，可以有效提高MySQL在处理大表时的查询性能和效率，从而减少查询时间和资源消耗，提升系统的整体性能。
无锁原子操作：
优点：
-
性能高效： 无锁原子操作通常比加锁操作更高效，因为它们避免了线程之间频繁的竞争和阻塞，减少了线程切换的开销。
-
避免死锁： 由于无锁原子操作不涉及锁的获取和释放，因此不会出现死锁的问题。
-
无锁定阻塞： 无锁原子操作不会造成线程阻塞，不会引起整个线程的挂起，提高了系统的吞吐量和响应性能。
缺点：
-
复杂性： 实现无锁原子操作相对复杂，需要处理各种并发冲突、内存屏障等细节，容易引入bug，调试和维护难度较大。
-
适用性： 无锁原子操作通常适用于较简单的并发场景，对于复杂的并发逻辑可能不够灵活，实现起来更加困难。
-
ABA问题： 在一些情况下，无锁原子操作可能会出现ABA问题，即一个值在操作前后经历了多次变化，但最终回到了原始值，这可能导致一些意料之外的结果。
加锁操作：
优点：
-
简单易懂： 加锁操作相对简单，容易理解和使用，适用于大多数并发场景。
-
通用性强： 加锁操作适用于各种并发场景，可以确保数据的原子性和一致性，能够应对复杂的并发逻辑。
-
稳定可靠： 使用锁能够确保线程之间的互斥访问，避免了竞争和数据不一致的问题，提高了系统的稳定性和可靠性。
缺点：
-
性能损耗： 加锁操作会引入线程阻塞和上下文切换的开销，可能导致性能下降，特别是在高并发场景下。
-
死锁风险： 加锁操作容易引发死锁问题，需要仔细考虑锁的获取和释放顺序，增加了编程的复杂性。
-
锁粒度问题： 锁的粒度过大或过小都会影响系统的并发性能，需要进行合理的锁粒度设计，这需要一定的经验和技巧。
综上所述，无锁原子操作和加锁操作各有优缺点，开发者需要根据实际情况和需求选择合适的并发控制方式。