【无标题】

HashMap的数据结构； put方法的细节； map中链表特别长之后会有什么变化； 扩容为什么每次都是扩大2倍，或者说为什么容量是2的幂次； put操作和扩容的先后顺序；

1. HashMap的数据结构： HashMap是基于散列表实现的键值对存储数据结构。具体来说，HashMap底层是一个数组，数组中的每个元素都是一个链表或者红黑树（JDK1.8之后）。数组中每个元素都表示一个“桶”，每个桶中可以存放一个或多个键值对。 2. put方法的细节： put方法的实现主要包括以下几个步骤： ①首先根据键的hashCode值算出存储位置（即计算该键值对应的桶号）。 ②如果桶中没有元素，则直接将键值对存入桶中。 ③如果桶中已经有元素（即存在冲突），则遍历链表或红黑树，找到对应的节点，如果找到了对应的节点，则覆盖原有的值；如果没有找到对应的节点，则将该键值对添加到链表或红黑树的末尾。 ④如果链表长度达到8，则将链表转化为红黑树。 ⑤如果桶的个数超过了阈值（即数组容量乘以负载因子），则进行扩容。 3. map中链表特别长之后会有什么变化： 当链表长度达到8时，HashMap会将链表转化为红黑树。红黑树相较于链表具有更高的查询效率。这也是为了避免退化成链表，导致查询效率降低。 4. 扩容为什么每次都是扩大2倍，或者说为什么容量是2的幂次： 扩容时将数组的容量增大一倍，主要是为了降低哈希碰撞的概率，减少冲突次数，进而提高散列表的性能。同时，容量是2的幂次也能够更好地支持扩容，因为在扩容时新数组的大小必须是原来大小的2的幂次，这样就可以更好地保证散列的均匀。 5. put操作和扩容的先后顺序： 首先进行put操作将键值对插入散列表中，然后判断是否需要进行扩容。如果需要扩容，则进行扩容操作，扩容后重新计算并插入原始数据到新的散列表中。

线程池：线程池的参数；

线程池是一种管理和复用线程的机制，可以提高应用程序的性能和可伸缩性，以下是线程池的一些参数： 1. 核心线程数（corePoolSize）：线程池中最少的并发线程数量，即线程池的基本大小。 2. 最大线程数（maximumPoolSize）：线程池中允许的最大并发线程数量。 3. 线程空闲时间（keepAliveTime）：空闲线程在被终止之前等待新任务的最长时间。 4. 时间单位（unit）：线程空闲时间的单位，如秒、毫秒等。 5. 任务队列（workQueue）：保存等待执行的任务的数据结构，有三类，分别为无界队列、有界队列和同步移交队列。 6. 饱和策略（rejectedExecutionHandler）：当任务无法被提交给线程池的饱和处理策略，有四种，分别为丢弃策略、丢弃队列中最老的任务策略、调用线程执行任务策略和调用者提供的策略。 线程池的参数可以根据不同的场景进行配置，以满足不同的需求。

redis内存满了redis会挂掉吗

当 Redis 的内存占满后，Redis 会根据设置的内存策略（maxmemory-policy）进行数据淘汰或者停止处理写入请求，转而只响应读取请求来保证可读性，但不会自动挂掉。如果此时写入请求依旧非常频繁，Redis 可能会继续占用内存直到系统崩溃或者进入 out-of-memory(OOM) 状态。因此，在使用 Redis 时需合理制定内存管理策略，并监控 Redis 内存状态，避免出现内存溢出导致 Redis 服务异常。

布隆过滤器的压力大可能是由于哈希函数数量或位数组大小不够导致的。有以下几种方法可以减轻布隆过滤器的压力： 1. 增加哈希函数数量：增加哈希函数数量可以减少冲突的发生，从而减少误判率。 2. 增加位数组大小：增加位数组大小可以增加过滤器的容量，但也会增加空间占用。 3. 使用加倍策略：可以动态调整位数组大小，当位数组使用率达到一定阈值时，自动加倍位数组大小。 4. 定期清空位数组：可以定期清空位数组，避免过多的历史数据影响过滤器的性能。 5. 使用多个布隆过滤器：可以将数据分散到多个布隆过滤器中，降低单一布隆过滤器的压力。

MySQL中的中间件有很多种，其中比较流行的包括： 1. MySQL Proxy：MySQL官方出品的中间件，可以拦截和修改MySQL协议的请求和响应。 2. MaxScale：由MariaDB出品的中间件，支持读写分离、负载均衡、数据路由等功能。 3. ProxySQL：一款高性能、高可用性的MySQL代理，支持多种负载均衡算法以及故障转移等功能。 4. Vitess：由YouTube开发的分布式数据库中间件，可以将MySQL集群扩展到数千个节点。 这些中间件可以帮助开发者轻松实现MySQL的负载均衡、高可用性、读写分离等功能，提高应用程序的性能和可靠性。

常见的线程安全容器包括： 1. ConcurrentHashMap：基于哈希表实现的并发哈希映射，支持高并发的读和写操作，能够在多线程环境下安全地进行元素的添加、修改和访问操作。 2. CopyOnWriteArrayList：基于数组实现的线程安全列表，它采用一种读写分离的策略，在写入数据时复制整个数组，并在新的数组上进行修改操作，保证了写入操作的线程安全性。 3. ConcurrentLinkedQueue：基于链表实现的线程安全队列，采用了无锁算法，在多个线程同时访问队列时能够保证插入和删除操作的线程安全性。 4. BlockingQueue：基于队列实现的线程安全容器，提供了阻塞式的操作方式，在队列为空或已满时能够实现线程的阻塞等待，用于解决生产者和消费者问题。 5. ConcurrentSkipListMap：基于跳表实现的线程安全有序映射，支持高并发的读和写操作，并且具有良好的时间复杂度和空间复杂度。

Spring AOP、IOC、DI介绍下

1. Spring AOP (面向切面编程)：AOP是Spring框架的核心之一，可以说是Spring区别于其他框架最主要的特性之一。AOP可以帮助开发者在业务逻辑代码外，优雅地聚焦和解决非功能性需求（例如安全性、日志、性能等问题）。Spring AOP核心就是基于动态代理或者字节码增强技术，在不修改原始业务逻辑代码的情况，将业务逻辑代码共同的负载，抽离到一个公共模块下进行统一管理，实现代码复用、提高可维护性的目的。 2. Spring IOC (控制反转)：控制反转是Spring框架的另一个重要特性，通过IOC容器可以在运行时动态注入属性、构造器参数和方法参数等，较好地解决了应用程序的开发难题。IOC容器能够统一管理和维护应用程序物件，让对象的依赖关系更加松耦合，使得对象间的通信和调用变得更加方便和自然。 3. Spring DI (依赖注入)：依赖注入是IOC容器的重要支持机制，通过DI可以将不同对象之间的依赖关系抽象出来，注入到对应的Bean实例。Spring容器能够自动完成对象实例的创建、调用、销毁等工作，让程序员能够专注于更关键的业务处理。 综上所述，Spring AOP解决的是代码的横向拆分问题；IOC解决的是对象之间的管理问题；DI解决的是依赖管理问题。同时，AOP、IOC、DI三者相互之间也有联系和互相支持，进一步加强了Spring框架作为优秀企业级应用开发框架的地位。

不使用依赖注入，使用传统方式的声明会有什么问题

使用传统方式进行依赖声明（如创建实例并将依赖对象传入构造函数或方法）会出现以下问题： 1. 高耦合性：传统方式会导致高度耦合的代码，每个对象都需要知道其依赖项的实例化方式，并直接创建这些依赖项。这样一来，当依赖项发生变化时，每个对象都需要修改其依赖项实例化的代码，影响整个应用程序的可维护性。 2. 难以模拟测试：传统方式可能会使单元测试变得困难，因为在测试环境中实例化依赖项，会增加测试代码的复杂性。 3. 可扩展性差：传统方式可以导致代码难以扩展，因为当需要添加新的依赖项时，需要在所有引用该依赖项的代码中进行修改。 因此，推荐使用依赖注入(DI)的方式，将依赖项的创建与对象的创建和使用分离，以解决上述问题。

前后端通信如何实现的？

前后端通信主要有以下几种方式： 1. AJAX：通过 Javascript 发送异步请求，从后台获取数据并更新页面内容，可以实现页面无刷新。 2. WebSocket：是一种全双工的通信协议，可以在客户端和服务端之间建立持久性连接，以实现双向通信。 3. HTTP 请求：浏览器向服务器发送 HTTP 请求，服务器通过 HTTP 响应返回数据。 4. RESTful API：基于 HTTP 协议的 RESTful 风格的 API，可以实现前后端的数据交互和通信。 5. GraphQL：一种新型的数据查询和操作语言，与传统的 RESTful API 相比，可以更加灵活地进行数据查询和操作，包含请求哪些数据，以及数据的格式等等。 以上是常见的前后端通信方式，选用哪种方式取决于需求和场景。

HTTP无状态的含义？

HTTP无状态（Stateless）是指服务器不会持续记录客户端的状态信息，即每次客户端发送请求时，服务器需要重新获取客户端的状态信息。这意味着，服务器之间的响应是根据每个请求独立计算的，而不会考虑以前的请求和响应。因此，服务器无法准确地知道两个请求是否来自同一个客户端。为了解决这个问题，服务器通常使用Cookie来存储客户端状态信息。这种无状态的特性使得HTTP协议可以处理大量同时请求的客户端，但也需要开发者在应用程序中处理这种“无状态”的情况。

在网页应用程序中，一般会使用 cookie 或 session 来判断用户是否已经登陆。 1. Cookie Cookie 是储存在用户计算机上的文本文件，里面包含了一些网站的信息，例如登录状态等。一旦用户登录成功，服务器可以在返回的 HTTP 响应中设置一个名为“cookie”的标头，该 cookie 包含一个可以唯一标识该用户的值，用于在之后的请求中识别用户身份。在之后的每个请求中，客户端浏览器都会自动附上该 cookie，以便服务器端验证用户是否已经登录。 2. Session Session 是指服务器端针对每个用户创建的一段运行时间，用于存储该用户的登录状态、购物车数据等信息。当用户登录成功后，服务器会为该用户创建一个 session，并向客户端浏览器发送一个名为“session ID”的特殊 cookie，包含了该 session 的唯一标识符。在之后的访问中，客户端浏览器会将该 cookie 自动附加到 HTTP 请求中，在服务器端通过解析该 cookie 来恢复该用户的 session 数据，从而维持用户的登录状态。 需要注意的是 cookie 的过期时间一般设置在较短的时间内（例如几分钟、几小时等），而 session 可以在用户关闭浏览器之前一直保持，因此对于较长时间的登录状态，使用 session 是更加安全和可靠的方法。

为什么基本不用session？

使用 session 有一些潜在的问题，可能是使用较少的一个原因。 1. 服务器性能问题：使用 session，服务器需要在内存中存储 session 数据，如果并发访问量较大，会占用大量的服务器运行资源，造成服务器性能问题。 2. 分布式部署问题：对于多台服务器集群部署的应用程序，由于 session 存储在某一台服务器上，因此需要特殊的负载均衡策略，才能实现在不同的服务器之间共享 session 数据，扩展起来比较复杂。 3. 安全性问题：session ID 是基于 cookie 或其它客户端标识传递的，在网络传输的过程中可能会被中间人劫持，从而导致安全问题。 因此，为了避免这些问题，一些开发者更倾向于使用轻量级、无状态的技术，如 JWT、OAuth 等，来替代 session，实现更高效、灵活的身份认证和授权。但是需要根据实际应用场景，权衡其利弊，做出合适的选择。