JAVA面试

免费的gpt4.0 https://api.fukaluosi.online/

不推荐使用select * 有哪些原因（什么情况下会导致索引失效）

使用SELECT *在SQL查询中通常不推荐出于以下几个原因：

1. 性能问题

• 数据传输量增加：SELECT *会检索表中的所有列，即使应用程序只需要几个字段。这会增加数据库和应用程序之间传输的数据量，导致网络带宽不必要的浪费，特别是在宽带受限的环境下。
• 缓存效率降低：数据库系统通常会缓存查询结果。如果每次查询都检索大量不必要的列，缓存中存储的冗余数据会更多，从而降低缓存效率。
• 影响索引使用：只查询必需的列更可能利用数据库的索引，从而提升查询效率。SELECT *可能导致数据库优化器忽略某些优化查询的索引。

2. 可维护性问题

• 代码清晰度：明确指定所需的列可以立即让阅读代码的人知道本次查询关注的数据字段，从而提高代码的可读性和可维护性。
• 避免隐式依赖：若数据库表结构发生变化（如增加或删除列），使用SELECT *可能会在不知情的情况下引入错误。明确指定列名可以避免因表结构变化导致的隐式依赖问题。

3. 数据安全性

• 减少敏感数据泄露：如果表中包含敏感或受保护的信息，使用SELECT *可能会无意间检索并泄露这些信息。只请求必要的字段可以降低泄露敏感信息的风险。

4. 兼容性问题

• 结果集的列顺序可能改变：如果表结构变化（例如，添加新列），使用SELECT *的代码可能会在不同时间得到不同的列顺序，这在处理结果集时可能会导致错误。

实践建议

• 明确指定需要的列，这样做即提高了性能，也增强了代码的可读性和健壮性。
• 定期审查和优化查询，确保它们符合当前的数据模型且效率最优。

综上所述，虽然使用SELECT *可能在某些快速原型设计或测试场景中提供便利，但在生产环境中为了提高性能、安全性和代码的可维护性，应该避免使用。

常见的优化方式以及良好的编码习惯列举

为了提高代码的性能和可维护性，遵循一些常见的优化方式和良好的编码习惯是非常重要的。下面分别列举了一些优化方法和良好的编码习惯供参考：

常见的优化方式

1. 算法优化：选择更高效的算法来解决问题。例如，使用快速排序替代冒泡排序。

2. 数据结构选择：使用合适的数据结构。例如，使用哈希表（HashMap）进行快速查找而不是使用列表遍历。

3. 循环优化：减少循环内部的计算量，避免重复计算，合理使用循环展开等技术。

4. 内存管理：避免不必要的内存分配和释放，使用内存池等技术来提高内存使用效率。

5. 并发和多线程：充分利用多核CPU的计算能力，但同时注意线程间的同步和数据一致性问题。

6. 延迟加载：按需加载资源，避免一次性加载全部资源造成的性能损耗。

7. 缓存技术：合理使用缓存，减少数据库或文件系统的访问次数。

8. 代码层面的优化：比如避免在循环中使用重型函数调用，减少不必要的变量声明和计算等。

9. 数据库优化：合理设计数据库索引，优化查询语句，避免全表扫描等。

良好的编码习惯

1. 代码可读性：合理命名变量和函数，遵循一致的代码风格，适当添加注释。

2. 避免全局变量的滥用：全局变量可能导致代码难以追踪和维护，尽可能使用局部变量或将变量封装在类/模块中。

3. 模块化和解耦：将代码分解成独立的模块，减少模块间的耦合，提高代码的复用性和可维护性。

4. 错误处理：合理处理错误和异常，避免程序崩溃或出现不可预料的行为。

5. 代码复用：避免重复代码，通过函数、类继承或模块等机制复用代码。

6. 持续重构：定期审视和重构代码，优化设计，提高代码质量。

7. 性能分析：使用性能分析工具定期检查代码性能，找出瓶颈进行针对性优化。

8. 遵守编程规范：团队内部制定并遵循统一的编程规范，有利于代码的阅读和维护。

通过遵循上述优化方式和良好的编码习惯，可以有效提升代码的性能和质量，同时也有助于提高开发效率和团队协作的流畅度。

B+树结构

https://blog.csdn.net/c630843901/article/details/121423196

水平分表

水平分表，又称为水平切分，是一种数据库优化技术，旨在通过将表中的数据分散到多个结构相同但数据不同的表中来提高数据库的查询速度和管理效率。这种技术在大型数据库系统中尤其有用，特别是当单一表中的数据量非常大时，通过水平分表可以有效地减少单个查询所需要处理的数据量，从而提高性能。

水平分表的主要优点包括：

1. 提高性能：通过减少查询操作需要扫描的数据量，可以显著提高查询响应时间。
2. 提高可扩展性：当数据库数据量增长时，可以通过增加更多的分表来分散数据，从而更容易地扩展数据库系统。
3. 数据管理：可以根据实际需要对数据进行更有针对性的管理，例如，可以将不同时间段的数据存储在不同的表中。

实现方法：

• 按范围分表：根据数据的某个属性值的范围来分表，例如，根据时间范围（如年份、月份）来分表。
• 按列表分表：根据数据的某个属性值来分表，例如，根据用户所在的地区来分表。
• 按哈希分表：根据数据的某个属性值的哈希结果来分表，可以均匀地分配数据到各个表中。

考虑因素：

在实施水平分表时，需要考虑多种因素，包括分表的依据、数据的访问模式、数据分布的均匀性以及应用程序的修改需求等。此外，水平分表也增加了数据库设计和管理的复杂性，需要适当的策略和工具来支持分表环境下的数据访问和管理。

结论：

水平分表是一种有效的数据库性能优化策略，适用于大型数据库系统，能够提高查询性能和系统的可扩展性。然而，它也需要细心的规划和管理，以确保数据的一致性和应用程序的正确运行。

binlog有什么用，如何使用binlog完成数据恢复

binlog（Binary Log）是MySQL数据库的一个非常重要的日志文件，主要记录了所有的DDL（Data Definition Language）和DML（Data Manipulation Language）语句（除了数据查询语言SELECT和SHOW等）的二进制日志。binlog有以下几个主要用途：

1. 数据复制：binlog是MySQL实现主从复制的基础，从服务器通过读取并执行主服务器的binlog来实现与主服务器的数据同步。
2. 数据恢复：当发生数据丢失或损坏时，可以通过binlog记录的语句来恢复数据。
3. 审计：通过分析binlog，可以知道哪些数据被修改了，以及何时被修改，帮助理解数据库的活动。

如何启用binlog

在my.cnf（或my.ini，取决于操作系统）配置文件中启用binlog，主要涉及以下配置项：

[mysqld]
log_bin=mysql-bin # 启用binlog并设置文件名前缀为mysql-bin
server_id=1       # 设置服务器ID，复制环境中每台服务器的ID必须唯一

配置完成后，重启MySQL服务使配置生效。

如何使用binlog完成数据恢复

数据恢复分为全量恢复和增量恢复两种情况：

1. 全量恢复：首先从最近的一次全备份开始恢复，然后应用之后所有的binlog日志。
2. 增量恢复：从某个时间点或某个事件后开始恢复数据，需要应用该时间点之后的所有binlog日志。

具体步骤如下：

1. 确定需要恢复数据的时间点或binlog文件及位置。
2. 使用mysqlbinlog工具将binlog文件转换为可执行的SQL文件。例如，要将名为mysql-bin.000001的binlog文件转换为SQL文件，可以使用以下命令：

   mysqlbinlog mysql-bin.000001 > binlog.sql
   

   如果是从特定位置开始，可以使用--start-position或--stop-position指定起始和结束位置，或者使用--start-datetime和--stop-datetime指定起始和结束的时间点。
3. 应用转换后的SQL文件到数据库：

   mysql -u root -p < binlog.sql
   

   这将会执行binlog.sql文件中的所有SQL语句，从而恢复数据。

请注意，数据恢复是一个比较精确且有时候复杂的过程，需要根据实际情况灵活调整，比如需要跳过某些事件或只恢复特定的数据库或表。在进行数据恢复之前，强烈建议在测试环境进行充分的测试。

数据库主键一般用什么类型

数据库主键一般使用以下类型：

1. 整数类型：通常是自增的整数，例如 MySQL 中的 INT AUTO_INCREMENT，SQLite 中的 INTEGER PRIMARY KEY AUTOINCREMENT。这种类型适合于大多数情况，因为它们简单、高效，并且不易出错。

2. 全局唯一标识符（GUID）或通用唯一标识符（UUID）：这些是全局唯一的字符串标识符，不同数据库系统中有不同的实现方式，例如 MySQL 中的 UUID() 函数，PostgreSQL 中的 uuid 数据类型。这种类型的主键适合分布式系统或需要在多个数据库之间唯一标识实体的情况。

3. 字符串类型：有时候也可以使用字符串作为主键，例如业务上有自然唯一标识符的情况。不过相比整数类型，字符串主键通常会导致性能下降，并且占用更多的存储空间。

选择主键类型通常要考虑数据库引擎的性能、数据的特点以及应用的需求。

UUID做主键的优缺点

UUID（Universally Unique Identifier）作为主键时，具有一定的优势，但也伴随着一些缺点。以下是UUID作为主键的一些主要优缺点：

优点：

1. 全局唯一性：UUID的主要特点是全球唯一性，这使得在分布式系统中，即使在不同的数据库或表之间，也能保证数据的唯一性和一致性。
2. 无需中心生成：使用UUID作为主键，不需要依赖数据库的自增长机制或单独的序列生成器，这在某种程度上简化了系统设计，尤其在分布式系统中更为明显。
3. 插入灵活性：由于UUID是在应用层生成的，这让记录的插入更加灵活，不依赖于数据库的插入顺序或位置。
4. 安全性：UUID的随机性较高，从而使得通过主键猜测数据记录更加困难，增加了数据的安全性。

缺点：

1. 存储开销：UUID通常是128位的，以16字节的存储大小远大于传统的整型主键（如32位的INT只需4字节）。这意味着更高的存储需求，对于拥有大量记录的数据库，这种差异会非常显著。
2. 性能问题：UUID的随机性导致它们在数据库中的存储不连续，这可能会影响到数据库在插入新记录时的性能，因为它可能需要频繁地重新排序和调整索引。特别是在基于B-Tree索引的数据库系统中，频繁的页面分裂可能会降低查询性能。
3. 可读性差：UUID是一长串的数字和字母组合，缺乏可读性，人工处理或在日志文件中查看时难以识别和记忆。
4. 复杂性增加：在某些情况下，使用UUID可能会增加应用逻辑的复杂性，例如在需要手动插入数据或进行调试时。

综上所述，是否使用UUID作为主键取决于具体应用场景的需求。对于需要高度唯一性和分布式系统的场景，UUID是一个很好的选择。但如果对存储空间和性能有较高要求，可能需要考虑其他替代方案。

字符串比较用什么方法？为什么不能用==

https://blog.csdn.net/qq_44543508/article/details/95449363

threadlocal的应用

https://cloud.tencent.com/developer/article/1636025

为什么用threadlocal存数据

ThreadLocal 类在 Java 中用于存储数据的原因主要是为了解决多线程环境下数据安全的问题，使得每个线程都有自己的数据副本，从而避免了线程之间的数据共享导致的冲突。具体而言，使用 ThreadLocal 存储数据有以下几个原因：

1. 线程隔离：ThreadLocal 为每个使用该变量的线程提供了独立的变量副本，因此每个线程都可以改变自己的副本，而不会影响到其他线程中的副本。这种机制是通过在内部为每个线程维护一个单独的变量值来实现的。

2. 简化参数传递：在一些复杂的业务流程中，如果需要将数据在多个方法或者类之间传递，使用 ThreadLocal 可以简化这种参数传递。因为 ThreadLocal 可以让每个线程看到的是自己独立的变量，所以可以将 ThreadLocal 变量当作是全局访问点来使用，避免了参数在多个方法或类之间的频繁传递。

3. 事务上下文的保持：在处理数据库事务时，可以利用 ThreadLocal 携带事务上下文信息（如当前事务的连接对象），确保在同一线程中执行的所有数据库操作都在同一个事务上下文中进行，从而简化事务管理。

4. 防止内存泄漏：虽然 ThreadLocal 在解决线程隔离问题上非常有用，但是如果不当使用，也可能导致内存泄漏问题。之所以提及这一点，并不是说 ThreadLocal 本身用于防止内存泄漏，而是开发者需要了解其使用时的内存泄漏风险，并采取措施（如适时清除 ThreadLocal 中的数据）来避免这种情况发生。

综上所述，ThreadLocal 提供了一种便捷的线程隔离机制，让数据在多线程环境下的管理变得更加安全和简单。然而，它的使用也需要格外注意，以防止可能的内存泄漏问题。

线程安全是？

可参考 https://blog.csdn.net/q669239799/article/details/90614077

线程安全（Thread Safety）是多线程编程中的一个概念，指的是在多线程环境下，无论主体运行时环境如何调度这些线程，并且无论这些线程的操作执行顺序如何，程序都能正常运行并提供正确的输出结果。

线程安全的实现通常需要考虑以下几个方面：

1. 互斥锁（Mutexes）：互斥锁可以保护共享数据，使得任何时候只有一个线程可以访问这部分数据。其他线程必须等待，直到数据被释放（解锁）之后才能访问。

2. 读写锁（Read-Write Locks）：它允许多个读操作同时进行而不会互相冲突，但是写操作会锁定整个资源直到完成，以确保写的安全性。

3. 原子操作（Atomic Operations）：原子操作是不可分割的操作，要么全部完成，要么全部不执行，不会出现只执行了一部分的情况。利用原子操作可以实现对共享数据的安全访问。

4. 无锁编程（Lock-Free Programming）：无锁编程是一种编程范式，它尽量减少或避免使用锁，通过其他机制比如原子操作来保证线程安全。这可以提高程序的性能，避免死锁等问题。

5. 条件变量（Condition Variables）：条件变量用于在线程之间同步共享数据的条件状态。当某个条件不满足时，线程可以等待条件变量，直到其他线程更新了条件并通知等待的线程。

6. 避免共享状态：另一种实现线程安全的策略是尽量避免共享状态。比如，可以将数据复制给每个线程，让每个线程都有自己的副本，这样就避免了线程间的冲突。

线程安全是并发编程中非常重要的概念，不正确的并发处理可能会导致数据不一致、死锁或程序崩溃等问题。因此，设计线程安全的程序需要仔细分析共享资源的访问和修改，以确保程序在多线程环境下的正确性和稳定性。

new User()(new 一个对象)在内存上的分配

参考这个 https://blog.csdn.net/l312770312/article/details/115440729

vue钩子函数 created() mounted()的区别

https://zhuanlan.zhihu.com/p/633576254

把一个盒子固定在右下角如何实现

要把一个盒子固定在浏览器的右下角，可以使用CSS的定位属性。这里主要有两种方法可以实现：使用绝对定位（position: absolute;）或固定定位（position: fixed;）。固定定位（position: fixed;）是相对于浏览器窗口来定位元素的，因此更适合需求，它确保元素即使在滚动页面时也会保持在视口的特定位置。

下面是使用CSS position: fixed; 实现的示例代码：

<!DOCTYPE html>
<html>
<head>
    <title>固定在右下角的盒子</title>
    <style>
        .box {
            width: 100px; /* 设置盒子的宽度 */
            height: 100px; /* 设置盒子的高度 */
            background-color: skyblue; /* 设置盒子的背景颜色 */
            position: fixed; /* 使用固定定位 */
            right: 0; /* 右边距设置为0 */
            bottom: 0; /* 底部边距设置为0 */
        }
    </style>
</head>
<body>

<div class="box"></div> <!-- 这是需要固定在右下角的盒子 -->

</body>
</html>

在这个例子中，.box 类被应用于一个<div>元素，使之成为一个盒子。通过设置position: fixed;，盒子被固定在视口中。right: 0; 和 bottom: 0; 确保盒子被放置在视口的右下角。无论页面如何滚动，这个盒子都会保持在浏览器窗口的右下角。

如果你想要盒子固定在页面的右下角，但在滚动页面时不随之移动，那么你可以使用position: absolute; 但这通常需要将其父元素设置为position: relative;来相对定位，这种方法在实际使用时可能不太适合固定在视口的右下角的场景。

什么是单元测试

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。至于“单元”的大小或范围，并没有一个明确的标准，“单元”可以是一个函数、方法、类、功能模块或者子系统。

单元测试中mock概念是什么意思？有什么优点

参考链接 https://developer.baidu.com/article/details/2771944

linux cpu占用变高 如何排查解决，如何是你写的api，你会如何去解决

当Linux系统的CPU占用率变高时，可能会导致系统性能下降，响应缓慢。定位并解决高CPU占用的问题通常需要一系列的分析和定位步骤。以下是一些检查和解决高CPU占用问题的建议步骤，包括如何处理你自己写的API导致的问题。

1. 确认CPU占用情况

首先，使用top或htop命令确认哪些进程正在使用CPU资源。这可以帮助你快速定位是系统级别的问题还是特定应用导致的问题。

top

或

htop

2. 分析特定进程

如果发现是特定的进程（比如你的API服务）占用了大量CPU资源，可以进一步分析该进程。使用pidstat可以查看特定进程的CPU使用情况，这有助于你了解CPU使用情况随时间的变化。

pidstat -p <PID> 1

3. Profiling和Tracing

如果确定是你的API导致了高CPU占用，那么需要对API应用进行性能分析（Profiling）和跟踪（Tracing）。根据你使用的编程语言和框架，可以选择不同的工具，如gprof, perf, py-spy（对于Python程序）等。

4. 优化代码

基于Profiling和Tracing的结果，找出CPU资源消耗最大的函数或代码段。可能的优化措施包括：

• 算法优化：寻找更高效的算法来减少计算量。
• 减少不必要的操作：移除或优化掉CPU密集型的操作，比如不必要的循环、密集的日志记录等。
• 并发和异步处理：如果可能，使用并发或异步编程模型来利用多核CPU，分散CPU负载。
• 资源缓存：对于重复的计算结果，考虑使用缓存来减少计算量。

5. 内存和I/O检查

有时，CPU占用高并不直接由CPU密集型操作引起，而是由于内存不足导致频繁的swap操作，或是I/O阻塞等待导致。使用vmstat和iostat等工具检查内存和I/O状况。

6. 软件和库的更新

确认你的应用以及其依赖的库都是最新版本。有时，性能问题可能是由旧版本的软件或库中的已知问题引起的。

7. 系统和硬件考量

如果上述步骤都不能解决问题，还需要考虑系统级别的配置和硬件性能问题，比如是否需要增加CPU资源、是否存在硬件故障等。

处理高CPU占用的问题通常需要综合考虑多种因素。仔细分析和定位问题的原因，逐步实施优化和调整，通常能有效降低CPU占用，提升应用和系统的性能。

怎么排查死锁？

排查死锁通常涉及几个步骤，包括识别死锁的存在、定位死锁发生的位置以及诊断导致死锁的原因。以下是一些常用的排查死锁的方法：

1. 使用系统工具和命令：

   • 对于数据库死锁，如MySQL，可以通过SHOW ENGINE INNODB STATUS;命令查看死锁日志。
   • 对于Java应用，可以使用jstack命令来获取Java应用的线程堆栈信息，分析哪些线程处于等待状态。
   • 在Linux系统中，可以使用top、ps、pstree等命令查看进程的状态，以及通过strace追踪系统调用和信号。

2. 分析日志文件：

   • 应用程序和系统日志文件经常记录有关死锁的信息，检查这些日志文件可以帮助发现死锁的迹象。

3. 利用调试器和分析工具：

   • 对于复杂应用，使用调试器（如GDB对于C/C++程序，或IDE自带的调试器如IntelliJ IDEA对Java程序）逐步执行代码，检查变量状态和线程执行情况。
   • 使用性能分析工具，例如MAT（Memory Analyzer Tool）对Java堆内存分析，或Valgrind工具检测C/C++程序中的内存问题，它们有时可以帮助发现死锁相关的问题。

4. 代码审核和检查：

   • 仔细检查涉及共享资源（如数据库、文件、内存）的代码逻辑，看是否存在可能导致死锁的模式，如不恰当的锁顺序。
   • 特别注意锁的获取和释放的顺序，确保所有线程或进程以相同的顺序获取锁。
   • 检查是否有忘记释放锁的情况。

5. 使用检测工具：

   • 有一些工具和库专门设计用来检测死锁，例如Java的FindBugs和Checkstyle可以帮助发现潜在的死锁问题。

6. 重现死锁场景：

   • 如果可能，尝试在开发或测试环境中重现死锁的场景，这有助于理解为什么会发生死锁并测试解决方案。

7. 避免和预防死锁：

   • 在设计系统时，采用预防死锁的策略，如避免嵌套锁、使用锁超时机制、按顺序获取锁等，可以减少死锁的发生。

排查死锁通常需要结合具体的应用场景和系统环境，通过综合使用上述方法，可以有效地定位和解决死锁问题。

bitemap如何做签到

https://blog.csdn.net/weixin_44606481/article/details/134446032

缓存击穿/穿透/雪崩概念及解决方案

参考上一期文章 https://blog.csdn.net/qq_52594679/article/details/137278485

消息的幂等性

https://blog.csdn.net/zengdongwen/article/details/100573824

业务性问题：全球的幼儿园在当地下午六点接受一封周报邮件，邮件中的数据来自于数据库,且需要进行处理，你会怎么做？

数据库中除去最基础的字段后，有很多不确定的用户自己需要的属性去扩展，你如何去设计数据库，

最后两题暂时没有想好怎么实现比较合适（个人方案觉得有不妥之处），有建议的大佬可以评论下，欢迎评论