综合类

1. mysql如何提高并发量？连接池的常用大小？

思考的点包括哪些？

1. 硬件方面：
   • 使用SSD提高IO速度；
   • 增加内存来提供更大的缓冲区，减少IO操作
   • 多核处理器：提供更多的并行能力
2. MYSQL配置优化
   • 调整innodb_buffer_pool_size（存储引擎的内存缓冲池大小），应调整为系统总内存的60%-80%
   • 调整innodb_log_file_size，适当增大日志文件大小可以提高写入性能
   • 使用持久连接：避免频繁建立和关闭连接
3. 查询优化：索引+避免复杂查询+优化数据表（optimize table）+数据库结构优化（消除数据冗余，使用更适当的数据类型）
4. 读写分离
5. 数据库分片
6. 连接池：复用数据库连接，减少建立和关闭连接的开销
7. 引擎更换：不需要事务且读多写少，上MyISAM
8. 避免锁竞争：通过代码优化和数据库设计，减少长期持有锁的情况

2. java程序如何提高并发量？

思考的点包括哪些？（数据库方面的参考上一个问题）

1. 多线程编程
2. 减少线程争用和使用更适当的并发集合，比如减少全局变量和静态变量的过渡使用
3. 垂直（单台机器加性能）和水平扩展（添加更多服务器以分摊负载），以及微服务分摊负载，负载均衡器来分发请求
4. JVM调整：调整堆大小和GC策略来减少垃圾回收暂停
5. 使用中间件和外部消息系统：消息队列异步处理请求，缓存减少对数据库访问
6. 避免阻塞，使用非阻塞IO或异步IO

3. java程序CPU占用100%，如何排查？

大概思路：

1. top确定CPU使用率，以及java进程的ID
2. 使用jstack <pid> > threadDump.txt 获得线程堆栈转储
3. 分析threadDump.txt文件，查找runnable状态的线程
4. 通过堆栈转储定位到具体的代码段，进行代码审查
5. 排除外部因素：数据库响应缓慢，网络延迟，外部服务延迟

VisualVM可以连接到运行中的jvm，其提供了采样器和探查器，可以定位导致高cpu使用率的代码段

4. redis的使用方式？

5. 索引优化的场景？（撕逼了很久）？

6. 一亿的键值对（时间，访问量），内存中怎么存？

7. 本机缓存、分布式缓存、多级缓存的优劣势？

8. top命令中的几个值的含义？（不知道他说的啥，就说了用户态、内核态、空闲态的cpu占用）

网络

1. 介绍下TCP和UDP的区别？TCP如何实现可靠传输？

2. Restful api常用的method？

PUT和PATCH方法的区别：

1. 意图：put幂等，主要目的是完全替换目标资源，也就是说，即使只改一个属性，也要提供完整的更新内容；patch用于部分更新目标资源，仅需提供资源中要修改的属性和新值，不一定是幂等的。
2. 资源不存在时：put可能会创建一个新资源，patch会返回一个错误。
3. 传输与安全性：put可以只传输修改部分，更搞笑，但是可能会产生安全性问题。

3. http的请求头

4. 你们为什么使用http来处理请求？

1. 简单：文本协议，人类可读，开发者能快读理解。
2. 无状态：请求独立，简化了服务器设计，并允许请求负载均衡。
3. 广泛支持：几乎所有的编程语言和平台都有库和框架来处理http交互，并且web浏览器的普及，且主流web浏览器都使用http作为主要通信协议、
4. 无需建立长连接：虽然http1.0和http1.1支持持久连接，但是大部分情况并不需要保持长时间连接，这对于节省服务器资源和处理并发请求非常有用。
5. 安全性：https为网站和用户提供了加密和身份验证，保护数据在传输过程中的安全性。

总结：简单、灵活、广泛受支持、并且能满足大多数web应用的需要。

5. Http1.1有无队头阻塞，并发模式？keepalive？

这里主要补充下http发展历史：

• http1.1相对http1.0的改进：

  • 使用长连接改善短连接造成的性能开销（keep-alive）
  • 使用管道网络传输，只要一个请求发送出去，不必等其回来，就可以发送第二个请求出去，减少整体的响应时间，即解决发送方的队头阻塞问题（这个大部分场景下不支持）

• http1.1的问题：

  • 请求/响应头部未压缩，首部信息越多延迟越大
  • 发送冗余的首部，每次互相发送相同的首部造成浪费较多
  • 服务器处理按请求顺序响应，如果服务器响应慢，客户端一直请求不到数据，会队头阻塞
  • 没有请求优先级控制
  • 请求只能从客户端开始，服务器只能被动响应

• http2相对http1.1的改进

  • 头部压缩：若同时发出多个请求，头一样或相似，会消除重复部分，使用hpack算法，维护头信息表，将字段入表，之后相同，则发送索引号。
  • 二进制格式：头信息和数据体都使用二进制，计算机无需在明文和二进制之间转换
  • 并发传输：解决队头阻塞问题，多个stream复用一个tcp连接，可乱序发送，服务器通过stream id区分，并组装成有序的http消息
  • 服务器主动推送资源：双方都可以建立stream，客户端用奇数，服务器用偶数。主要用于服务器提前发送客户端可能需要的资源，减少时延和开销。

• http2的缺点：

  • 队头阻塞：stream看似解决http1的队头阻塞，但是无法解决发生在tcp层面的阻塞，tcp需要包有序，如果无序，则会将后续包放入缓冲区，一旦发生丢包，会出发重传，一个tcp连接中所有http请求都必须等待这个丢了的包被重传回来。（实际上是响应端的队头阻塞）

• http3相对http2的改进：

  • 将会发生阻塞的tcp换成了udp，并通过quic协议来实现类似tcp的可靠传输
    • 无队头阻塞：某个stream丢包，只阻塞这个stream，不影响其他stream
    • 更快的连接建立：过去tcp和tls是分层的，需要分批次握手，而quic内部包含了tls，可以在一个rtt内（三次握手）完成连接简历和密钥写上
    • 连接迁移：tcp使用四元组来确定一条tcp连接，若切换网络环境，IP地址变了，必须断开连接，重新建立（tcp和tsl分别握手+tcp慢启动，时延很高，迁移成本高），而quic使用连接id来分别标记双方，ip地址变化后，也可以无缝复用原连接，无需重连，没有卡顿。

• http3的缺点：

  • 很多网络设备不知道quic，只知道udp，有的网络设备会丢弃udp。
  • 普及缓慢

Keep-Alive是http1.1头部，与持久连接有关，持久连接希望在http请求在传输完数据后保持连接打开，以便之后的请求可以重用该连接，减少频繁建立和关闭连接带来的开销。

http1.1的头部信息，http2中默认支持多路复用，以下头部字段不需要

# 代表打开持久连接
connection:keep-alive 

# 保持打开状态5s，并且可以被重用1000次
Keep-Alive: timeout, max=1000

Java

1. 介绍下哈希查找的过程？

2. BIO和NIO

还需要更新 java中两种主要的IO处理方式，主要区别在于是否允许线程在等待数据时被阻塞。

1. BIO（Blocking IO）
   • 阻塞模式：当线程调用read或write方法 ，该线程被阻塞，直到数据被读取或写入，或者发生某个异常，这意味着其他IO操作必须等待当前操作完成。
   • 模型简单：模型简单，流程清晰
   • 效率问题：每次IO都会导致线程被阻塞，如果请求并发量大，需要创建大量线程来处理IO，导致资源浪费和系统压力增加。
2. NIO（Non-blocking IO）
   • 非阻塞模式：线程调用read，如果没有数据可读，线程可以继续执行其他任务，write同理。线程通常将非阻塞IO的空闲时间用于在其他IO通道上执行IO操作，所以单个线程可以管理多个数据输出。
   • 缓冲区：NIO引入了缓冲区的概念，数据的读写都是基于缓冲区进行的，缓冲区实质上是一个数组
   • 选择器：NIO引入了selector的概念，选择器可以监视多个IO通道，检查那个通道已经准备好了读写，使得一个线程可以管理多个通道。
   • 灵活性增加，但是编程复杂度也增加。

数据结构与算法

1. IPv4转int，int转IPv4（手写）

2. 汉诺塔（手写）

3. 排序算法？介绍下快排？

4. 介绍下查找算法？

还有二叉搜索树查找，平衡树查找，b树b+树查找，索引查找,跳表查询

5. 链表和数组？