Java面试题集锦一

最新推荐文章于 2024-10-01 18:51:18 发布

weixin_44416039

最新推荐文章于 2024-10-01 18:51:18 发布

阅读量686

点赞数 31

分类专栏： Java工程师面试文章标签： java 面试开发语言

本文链接：https://blog.csdn.net/weixin_44416039/article/details/139255264

版权

Java工程师面试专栏收录该内容

66 篇文章 0 订阅

订阅专栏

问：线程池的核心线程数是20，最大线程600，阻塞队列200，当qps是200的时候，请求一个耗时较长的第三方接口阻塞超时，请问不能加机器的前提下怎么提高吞吐量

答：在不能加机器的情况下，可以尝试以下几种方法来提高线程池的吞吐量：

调整阻塞队列大小：可以将阻塞队列的大小适当调大，比如将队列大小调整为300，可以增加队列中可以缓存的请求数量，从而减少因为阻塞队列已满而导致请求被拒绝的情况。
优化第三方接口调用：可以对第三方接口的调用进行优化，比如使用连接池、重试机制、超时机制等，减少因为第三方接口阻塞而导致线程池阻塞的情况。
优化线程池参数：可以根据实际情况调整线程池参数，比如增加核心线程数、最大线程数、阻塞队列大小等，以满足实际需求。
引入异步处理：可以将请求放入队列中后，立即返回响应，然后异步处理队列中的请求。这种方式可以提高并发处理能力，但需要根据具体情况考虑是否适用。

需要注意的是，提高吞吐量不仅仅是通过调整线程池参数就能够实现的，还需要结合具体业务场景和实际运行情况来综合考虑，才能够找到最优的方案。

问：将请求放入队列中后，立即返回响应，然后异步处理队列中的请求。这种方式在Java8中如何实现

答：在Java 8中，可以使用CompletableFuture和ExecutorService来实现将请求放入队列中后，立即返回响应，然后异步处理队列中的请求的功能。

具体实现步骤如下：

创建一个ExecutorService线程池来异步处理请求。

ExecutorService executor = Executors.newFixedThreadPool(10);

将请求放入队列中，并使用CompletableFuture来异步处理队列中的请求。

CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
    // 异步处理队列中的请求
}, executor);

在请求被放入队列中后，立即返回响应。

// 立即返回响应
response.getWriter().write("Request accepted.");

// 继续执行下面的代码

完整代码示例

// 创建一个ExecutorService线程池
ExecutorService executor = Executors.newFixedThreadPool(10);

// 将请求放入队列中，并使用CompletableFuture来异步处理队列中的请求
CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
    // 异步处理队列中的请求
}, executor);

// 立即返回响应
response.getWriter().write("Request accepted.");

// 继续执行下面的代码

使用这种方式可以大大提高系统的并发处理能力和响应速度。需要注意的是，为了防止请求过多导致系统崩溃，可以通过限制队列的长度或者使用限流算法来控制请求的数量。

问：redis中有一批key瞬间过期，为什么其他key的读写效率会降低

答：当 Redis 中有一批 key 瞬间过期时，可能会引起 Redis 的内部机制 —— 清除过期 key 的操作，导致其他 key 的读写效率降低。 Redis 清除过期 key 的机制是定期遍历所有的 key，找出过期的 key 并删除。这个过程会占用 Redis 的 CPU 资源和内存带宽，特别是在有大量 key 过期的情况下，会导致清除操作的负载很高。同时，当 Redis 清除过期 key 时，会阻塞其他的 Redis 操作，因为 Redis 是单线程模型的，所有的操作都是串行执行的。如果清除过期 key 的操作占用了大量的 CPU 资源和内存带宽，就会导致其他操作被阻塞，从而影响 Redis 的读写效率。因此，为了避免这种情况，我们应该尽量避免一批 key 在同一时刻过期，可以考虑将过期时间设置为随机值，或者分散到不同的时间段。此外，我们还可以通过增加 Redis 实例、扩容集群等方式，提升 Redis 的性能和承载能力，以保证 Redis 的正常运行。

问：当数据库的数据量达到1000万以上，如何进行分页操作查询

答：当数据库的数据量达到1000万以上时，进行分页操作查询可以考虑以下几种方法：

使用 LIMIT 分页：LIMIT 是一种基本的 SQL 分页方式，可以限制查询结果返回的记录数和起始位置，通过修改起始位置和限制数量来实现分页。但是，当数据量非常大时，使用 LIMIT 分页可能会导致查询性能下降，因为数据库需要扫描大量的数据并返回结果集，还需要进行大量的排序和聚合操作。
使用游标分页：游标分页是一种比较高效的分页方式，可以利用数据库的索引实现分页，避免全表扫描。具体实现方式是记录当前分页查询的最后一条记录的主键值，下一次查询时以该值为起点，继续向下查询指定数量的记录。这种方式比 LIMIT 分页性能更好，适用于数据量比较大的场景。
预分页：预分页是一种将数据预处理后，存储到缓存中，供分页查询时直接读取的方式。这种方式可以有效地减轻数据库的查询压力，提升查询性能。但是，需要注意缓存更新的问题，否则可能会导致数据不一致。
数据库分库分表：当数据量非常大时，可以考虑使用数据库分库分表技术，将数据按照一定的规则分散到多个数据库或表中，从而提升查询性能。但是，需要注意数据一致性和操作的复杂性问题。

需要根据具体情况选择合适的分页方式，综合考虑查询性能、数据一致性和操作的复杂性等因素。

问：怎么清晰详细的表达滑动窗口限流算法

答：滑动窗口限流算法是一种常用的流量控制算法，可以控制系统的并发度和吞吐量，从而保证系统的稳定性和可靠性。该算法的基本思想是在一段时间内，限制请求的数量不能超过一个阈值，如果超过阈值，则拒绝后续的请求。

滑动窗口限流算法的实现过程如下：

定义一个固定大小的时间窗口，比如 1 秒、5 秒、10 秒等，窗口内的请求数量不能超过阈值。
将时间窗口划分为若干个小窗口，每个小窗口的时间间隔是固定的，比如 1 毫秒、10 毫秒、100 毫秒等，小窗口内的请求数量不能超过阈值。
维护一个滑动窗口，记录当前时间窗口内的请求数量和请求时间戳，每次有请求到来时，检查当前时间戳是否在时间窗口内，如果是，则将请求计数器加 1，否则，滑动时间窗口，重新开始计数。
判断请求数量是否超过阈值，如果超过，则拒绝后续的请求，否则允许请求继续执行。

具体实现中，可以使用数组、链表等数据结构来维护滑动窗口，每次有请求到来时，更新滑动窗口的计数器和时间戳，然后遍历滑动窗口，统计窗口内的请求数量，判断是否超过阈值。

需要注意的是，滑动窗口限流算法只能对瞬时流量进行限制，无法对长期平均流量进行限制，同时需要根据具体情况选择合适的时间窗口大小和阈值，以保证系统的正常运行。

问：查询接口调优，不能用缓存，要求实时性，具体需要怎么调优

答：如果不能使用缓存，并且需要保证查询接口的实时性，那么就需要通过调整查询语句和数据库的配置来提高查询效率，具体可以从以下几个方面入手：

优化查询语句：对查询语句进行优化可以提高查询效率。可以通过使用索引、优化 JOIN 操作、避免使用子查询、减少使用 DISTINCT 等方式来优化查询语句，可以用group by来实现distinct。
配置数据库参数：合理的配置数据库参数可以提高查询效率。比如，可以适当增大缓冲池和连接池的大小，减少死锁和死循环的发生，优化数据库的缓存和索引等。
优化表结构：合理的表结构设计可以提高查询效率。可以通过合理的数据类型选择、避免过度规范化、使用分区表等方式来优化表结构。
使用优化工具：可以使用一些优化工具来帮助定位和优化查询性能问题，比如 MySQL 的 Explain 工具可以分析查询语句的执行计划，从而找出问题所在。
使用数据库集群：如果单台服务器的处理能力无法满足需求，可以考虑使用数据库集群来提高查询性能。数据库集群可以将查询请求分散到多个服务器上处理，从而提高查询效率。

需要注意的是，对于实时性要求高的查询接口，优化查询语句和配置数据库参数是最为重要的。同时，还需要根据具体情况进行调整和优化，以达到最优的查询效率。

问：详细讲解一下mysql的索引原理、结构

答：MySQL中的索引是用于加速查询的一种数据结构，它可以快速地定位到符合条件的数据行。索引在数据库中起到非常重要的作用，对于数据库的性能和查询效率都有着至关重要的影响。

一、索引原理

B-Tree索引 MySQL使用B-Tree索引来实现索引。B-Tree是一种平衡树，它的每个节点存储多个关键字，每个关键字指向一个子树，使得查询时只需经过一定的层级即可找到目标数据。B-Tree索引由根节点、叶子节点、中间节点等组成，其中根节点和中间节点存储了关键字和指向下一级节点的指针，叶子节点则存储了完整的数据行。
索引分类 MySQL中的索引可以分为主键索引、唯一索引、普通索引等几种类型。其中主键索引和唯一索引可以保证索引值的唯一性，普通索引则不做限制。主键索引和唯一索引的区别在于主键索引可以为空，而唯一索引不可以。
索引的优缺点索引可以加快查询速度，提高数据检索效率。但同时，索引也会带来一些额外的开销，包括索引的维护、空间占用等。因此，在创建索引时需要权衡索引的优劣，避免不必要的索引带来的负面影响。二、索引结构 MySQL的索引结构可以分为聚簇索引和非聚簇索引两种。
聚簇索引聚簇索引指的是数据按照主键值的顺序排列，即将数据和索引放在同一个B-Tree中。聚簇索引的优点是可以加速查询，因为数据行存储在同一个B-Tree节点中，相邻的数据行也会存储在相邻的B-Tree节点中，这样可以提高查询效率。但是，聚簇索引也存在一些缺点，例如插入新数据时需要进行大量的移动操作，因此在高并发场景下，聚簇索引的性能可能会受到影响。
非聚簇索引非聚簇索引指的是将索引和数据分开存储，数据存储在一个B-Tree中，而索引存储在另一个B-Tree中。非聚簇索引的优点是插入数据时不需要进行大量的移动操作，因此在高并发场景下，非聚簇索引的性能相对较好。

问：mysql非聚簇索引的使用注意事项

答：非聚簇索引在MySQL中非常常见，因为它们可以有效地提高查询效率。但是，在使用非聚簇索引时，也需要注意一些事项，以确保索引能够发挥最大的作用，不影响数据库性能。

下面是一些使用非聚簇索引的注意事项：

考虑索引的选择性选择性是指索引列上不同值的数量与表中数据行数的比例。选择性越高，索引的效率就越好。因此，在创建非聚簇索引时，应该优先选择选择性高的列作为索引列。
尽可能选择较短的索引列较短的索引列可以减小索引的大小，提高查询效率。因此，应该尽可能选择较短的索引列作为索引。
避免创建过多的索引过多的索引会占用大量的磁盘空间，并且会降低数据修改的效率。因此，在创建非聚簇索引时，应该避免创建过多的索引。
避免在索引列上进行函数操作在索引列上进行函数操作，会导致MySQL无法使用索引，从而降低查询效率。因此，在创建非聚簇索引时，应该避免在索引列上进行函数操作。
尽量避免使用LIKE操作符 LIKE操作符通常不能利用索引，因此，在使用非聚簇索引时，应该尽量避免使用LIKE操作符。如果必须使用LIKE操作符，可以考虑使用全文索引。
尽量避免使用NOT操作符 NOT操作符通常也不能利用索引，因此，在使用非聚簇索引时，应该尽量避免使用NOT操作符。如果必须使用NOT操作符，可以使用UNION操作来代替。
维护索引的统计信息索引的统计信息包括索引列的值分布情况、数据行数等信息。这些信息对于MySQL优化查询计划非常重要。因此，在使用非聚簇索引时，应该定期维护索引的统计信息。

问：redis 的set 底层什么时候是hash，什么时候是跳表

答:在 Redis 中，Set 数据结构有两种实现方式，分别是哈希表和跳表。

当 Set 中元素数量较小（小于等于 512 个），且所有元素大小都不超过 64 字节时，Redis 会采用哈希表实现 Set。这是因为哈希表的优点是在数据量较小的情况下，查询和插入的效率都非常高，且哈希表对于较小的元素能够更好地利用内存。

当 Set 中元素数量较大时，Redis 会采用跳表实现 Set。跳表是一种有序数据结构，它可以支持快速的插入、删除和查找，其时间复杂度均为 O(log n)，并且跳表的空间复杂度也相对较低。因此，当 Set 中元素数量较大时，Redis 采用跳表实现 Set 能够更好地支持高效的数据操作。

需要注意的是，当 Redis 存储的 Set 中元素数量发生变化时，它可能会从哈希表转换成跳表，或者从跳表转换成哈希表。这是因为在 Redis 的实现中，为了保证 Set 操作的效率和内存使用效率，Redis 会根据数据量大小和元素大小的变化，动态调整 Set 的底层实现方式。

问：现在用户要查询一张表，当流控降级时，兜底方案应该是怎么样的？

答：当流控降级时，我们需要提供一种兜底方案来保证服务的可用性，一般可以考虑以下几种方案：

返回空数据或默认数据：可以在业务中预定义一些默认数据或者空数据，当服务降级时，直接返回这些数据。这种方案的优点是实现简单，对服务的压力很小，但缺点是可能会给用户带来困惑和不良体验。
异步调用：当请求过多时，可以将请求异步地放入消息队列中，由后台服务慢慢处理，并将处理结果保存在缓存中，然后再返回给用户。这种方案的优点是可以避免阻塞请求线程，但缺点是需要额外的队列和后台服务支持，增加了系统的复杂性。
降级缓存：可以将一些经常被查询的数据提前缓存起来，当服务降级时，直接从缓存中返回数据。这种方案的优点是可以减轻数据库的压力，提高系统的性能，但缺点是缓存可能存在数据不一致的问题。
错误重试：当服务降级时，可以将请求重试一定的次数，直到服务恢复正常为止。这种方案的优点是可以保证服务可用性，但缺点是可能会增加服务器的负担。

需要根据具体业务场景，选择适合的兜底方案。在选择方案时，应当综合考虑服务的性能、可用性、用户体验和系统复杂度等因素。

问：spring 中解决循环依赖为什么要用三级缓存，二级为什么不行呢

答：在Spring中解决循环依赖的过程中，Spring容器需要在对象创建过程中维护一个缓存来避免重复创建和解决循环依赖问题。Spring容器使用三级缓存的方式来实现循环依赖的解决。

三级缓存包括：singletonObjects、earlySingletonObjects、singletonFactories。

其中：

singletonObjects：用于存储已经完全创建好的单例对象，如果容器中已经有该对象则直接返回。
earlySingletonObjects：用于存储已经创建出来但是尚未完成初始化的单例对象，即对象还没有被完全填充属性。此时，Spring容器会把该对象进行提前暴露，以便在后续对象创建时使用，从而解决循环依赖的问题。
singletonFactories：用于存储提前曝光的bean的工厂方法对象。Spring容器会在对象初始化时，调用该工厂方法对象生成一个完全初始化好的对象，并将该对象返回。

为什么使用三级缓存而不是二级缓存？

在使用二级缓存时，当对象A需要注入对象B，而对象B又需要注入对象A时，如果在第一次创建对象A时，对象A中包含了对对象B的引用，那么Spring容器会创建对象B并注入到对象A中。此时，对象B中如果包含了对对象A的引用，Spring容器会再次创建对象A并注入到对象B中。如果此时对象A中包含了对对象B的引用，Spring容器会又再次创建对象B，如此反复，就会形成一个死循环，导致StackOverflowError。

为了避免这种情况的发生，Spring引入了三级缓存的概念，通过提前暴露未完全初始化的单例对象来解决循环依赖的问题，从而避免了上述死循环的问题。因此，使用三级缓存可以更好地解决循环依赖的问题。

问：详细说明一下spring中如何使用三级缓存解决循环依赖问题

答：Spring中通过三级缓存解决循环依赖问题的过程可以分为以下几个步骤：

Spring容器创建对象时，将该对象放入singletonFactories缓存中。
如果该对象中存在其他对象的引用，则需要等待该对象创建完成后才能注入其他对象。此时，Spring容器会将该对象放入earlySingletonObjects缓存中，并将其标记为“未完成初始化”。
如果其他对象在创建过程中需要引用到该对象，Spring容器将会直接从earlySingletonObjects缓存中获取该对象并返回，此时还未完成初始化，因此对象的属性为空或者部分填充。
当该对象创建完成后，Spring容器会将该对象移动到singletonObjects缓存中，此时该对象已经完成初始化。

下面是一个简单的示例来说明Spring中使用三级缓存解决循环依赖的过程：

public class A {
    private B b;

    public A(B b) {
        this.b = b;
    }
}

public class B {
    private A a;

    public void setA(A a) {
        this.a = a;
    }
}

在这个示例中，类A中包含了对类B的引用，而类B中也包含了对类A的引用，这就会导致循环依赖的问题。使用Spring的三级缓存可以解决这个问题，示例代码如下：

@Configuration
public class AppConfig {
    @Bean
    public A getA(B b) {
        return new A(b);
    }

    @Bean
    public B getB(A a) {
        B b = new B();
        b.setA(a);
        return b;
    }
}

在上面的代码中，类A和类B都被定义成了Spring容器中的Bean。在获取Bean的过程中，Spring容器会使用三级缓存的方式解决循环依赖问题。

具体的解决过程如下：