【金三银四】每日一点面试题（面经汇总）百分点java一面1.12

最新推荐文章于 2024-07-27 17:56:15 发布

鄒彬

最新推荐文章于 2024-07-27 17:56:15 发布

阅读量944

点赞数 21

文章标签： java 开发语言 jvm

本文链接：https://blog.csdn.net/Z70769691/article/details/136477060

版权

本文题目要来源：牛客网–byebyeneu：https://www.nowcoder.com/feed/main/detail/bdd7a04048cc4ef1ae5963b96f4e4f1b

百分点java一面1.12（35题）

前言
1. 四种引用区别
2. ThreadLocal在引用上的问题
3. JVM区域
4. 双亲委派机制
5. HashMap原理
6. Java中实现多线程的方式
7. 线程池数量参数设置一般怎么设
- CPU密集型任务跟 IO密集型任务如何区分
8. Runnable和Callable区别
9. Java线程怎么得到执行结果
10. CAS（Compare and Swap）原子操作
11. Spring的核心注解、组成、过程
- - 核心注解：
  - 组成与过程：
12. Spring开发常用工具类
13. Spring开发中异常处理
14. Spring自动装配、两个注解区别
- - `@Autowired`（Spring框架提供）
  - `@Resource`（Java EE标准，Spring也支持）
15. Spring MVC的过程
16. 解决循环依赖的方法
- - 在Spring框架中的解决方案：
  - - 1. 单例Bean的循环依赖处理：
    - 2. 代码层面的解决策略：
- 三级缓存
- - 示例
17. MyBatis中$号和#号的区别
18. MySQL数据库引擎及区别
19. 四种隔离级别
20. 索引的分类
21. 慢查询优化方法
22. Redis数据类型
23. Redis持久化机制
24. 常用的持久化方式
25. Redis为什么设计成单线程
26. 实现Redis一致性的方法
27. Nacos和Eureka区别
28. TEXT和CHAR的区别
29. CHAR和VARCHAR的区别
30. 反射和使用场景
31. Docker常用命令
32. Docker部署JAR包的过程
33. Linux远程拷贝命令
34. Linux实时查看日志命令
35. Linux解压ZIP命令

前言

八股拷打的巅峰，纯纯八股

1. 四种引用区别

在 Java 中，通常涉及到四种引用类型的概念：强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference）。这些引用类型在垃圾回收机制中有不同的作用和行为：

强引用（Strong Reference）：
- 强引用是Java中默认的引用类型。
- 强引用是最常见的引用类型，它会确保被引用的对象不会被垃圾回收器回收。
- 只有当没有任何对象引用一个特定的对象时，该对象才会被垃圾回收器回收。

Object strongRef = new Object(); // 创建一个强引用

软引用（Soft Reference）：
- 软引用用于描述一些还有用但非必需的对象。在系统将要发生内存溢出之前，垃圾回收器会选择性地回收软引用对象。
- 如果内存充足，软引用不会被回收；但当内存不足时，垃圾回收器会回收这些对象。

import java.lang.ref.SoftReference;

Object obj = new Object();
SoftReference<Object> softRef = new SoftReference<>(obj); // 创建一个软引用

obj = null; // 解除原始对象的强引用，可以被垃圾回收

弱引用（Weak Reference）：
- 弱引用也用于描述一些非必需对象，但是比软引用更弱。
- 当垃圾回收器运行时，无论内存是否充足，弱引用都会被回收。

import java.lang.ref.WeakReference;

Object obj = new Object();
WeakReference<Object> weakRef = new WeakReference<>(obj); // 创建一个弱引用

obj = null; // 解除原始对象的强引用，可以被垃圾回收

虚引用（Phantom Reference）：
- 虚引用也称为幽灵引用或者幻影引用，它的存在意义在于帮助跟踪对象被垃圾回收的状态。
- 通过虚引用，可以在对象被垃圾回收时收到一个系统通知，进行一些清理工作。

import java.lang.ref.PhantomReference;
import java.lang.ref.ReferenceQueue;

Object obj = new Object();
ReferenceQueue<Object> referenceQueue = new ReferenceQueue<>();
PhantomReference<Object> phantomRef = new PhantomReference<>(obj, referenceQueue); // 创建一个虚引用

obj = null; // 解除原始对象的强引用，可以被垃圾回收

// 在对象被回收时，会将引用加入到 referenceQueue 中
Reference<? extends Object> polledRef = referenceQueue.poll();
if (polledRef != null) {
    System.out.println("Object referenced by phantomRef has been garbage collected.");
}

在 Java 中，这些引用类型的选择取决于对对象生命周期管理的需求。强引用适用于确保对象不被回收的情况，而软引用、弱引用和虚引用则提供了更灵活的对象管理方式，允许在一定条件下让对象被垃圾回收。

主要区别：
1、生命周期：强引用的生命周期最长，对象只有在不再被强引用时才会被回收。软引用在内存不足时会被回收，弱引用在垃圾回收时总会被回收，而虚引用在对象即将被回收时会收到通知。
2、用途：强引用用于程序中的关键对象，软引用用于缓存，弱引用用于弱缓存或非必需对象的维护，虚引用用于跟踪对象回收的状态。
3、回收时机：强引用不会被垃圾回收器主动回收，除非显式设置为null。软引用在内存不足时被回收，弱引用在垃圾回收时被回收，虚引用用于在对象被回收时得到通知。

2. ThreadLocal在引用上的问题

ThreadLocal是Java中的一种线程绑定的变量存储类，它为每个线程都创建了一个独立的变量副本，每个线程都可以改变自己的副本而不会影响其他线程所对应的副本。

然而，在使用ThreadLocal时，需要注意其在引用上的问题：

内存泄漏：当线程结束后，如果不清理ThreadLocal，那么它所持有的对象不会被垃圾回收。因为在ThreadLocal内部有一个ThreadLocalMap，用于存储每个线程的变量副本，这个ThreadLocalMap的键是ThreadLocal实例自身，如果线程结束了但没有删除对应的键值对，那么这个ThreadLocal实例和它引用的对象就无法被回收，从而导致内存泄漏。因此，推荐在不再需要ThreadLocal时调用remove()方法或者在使用ThreadLocal的线程实现Runnable或Callable接口时，在完成任务后主动清理。
线程复用：如果线程池中的线程被复用，新的任务可能会继续访问到上一个任务设置在ThreadLocal中的值，这可能不是预期的行为。所以，在线程池场景下，更应该注意清理ThreadLocal。
ThreadLocal并不是线程安全的数据结构，它的安全性体现在每个线程只能访问到自己的副本，而不是说多个线程可以同时安全地操作同一个ThreadLocal实例。在初始化、设置和删除ThreadLocal的值时，仍然需要保证当前线程只有一个线程在进行这些操作。
对象引用：由于ThreadLocal通常用来存储对象引用，当线程结束但对象还在被其他地方引用时，即使清理了ThreadLocal，对象也不会被垃圾回收，这也可能导致内存泄漏。所以在设计时应合理管理对象生命周期，避免长生命周期的对象通过ThreadLocal引用而导致资源无法释放。

3. JVM区域

JVM（Java虚拟机）在执行Java应用程序的过程中，将其管理的内存划分为多个逻辑区域，这些区域根据其特性和生命周期大致可以分为以下几个部分：

程序计数器（Program Counter Register）
- 每个线程都有一个独立的程序计数器，用于保存当前正在执行的字节码指令的地址。
- 它是线程私有的，也是唯一一个在《Java虚拟机规范》中没有规定任何OutOfMemoryError情况的区域。
虚拟机栈（Java Virtual Machine Stacks）
- 每个线程也有自己的虚拟机栈，栈中的元素是栈帧，每个栈帧对应着一次方法调用。
- 栈帧中包含局部变量表、操作数栈、动态链接、方法出口信息等，用于支持方法的调用和返回。
本地方法栈（Native Method Stacks）
- 类似于虚拟机栈，但它服务于JNI（Java Native Interface）调用的本地方法。
- 它也是线程私有的，存储本地方法的状态信息。
Java堆（Heap）
- 所有线程共享的内存区域，主要用于存放对象实例和数组。
- 新生代（Eden、Survivor 区）、老年代（Old Gen）和永久代/元空间（PermGen/Metaspace）是堆内存的不同分区，分别对应不同生命周期的对象存储。
- 在Java 8及更高版本中，永久代的概念被元空间取代，元空间不在堆内，而是直接使用本地内存。
方法区（Method Area）
- 也是所有线程共享的内存区域，用于存储已被虚拟机加载的类的信息、常量、静态变量、即时编译器编译后的代码等数据。
- 在Java 8之前，这部分被称为永久代，但在Java 8及以后版本中，永久代的功能转移到了元空间。

每个区域都有自己的大小限制，并且在特定情况下可能会抛出如StackOverflowError（栈溢出）或OutOfMemoryError（内存溢出）等错误。此外，Java虚拟机在执行过程中会对这些内存区域进行管理和优化，比如垃圾回收机制主要针对的就是堆内存。

4. 双亲委派机制

双亲委派机制是Java虚拟机（JVM）中类加载器的一个重要规则。在Java中，类加载器负责从文件系统或网络中加载类的二进制数据，并将类信息转换成方法区内的运行时数据结构，然后在Java应用运行时创建类和接口的实例。

双亲委派模型的工作原理如下：

当一个类加载器收到类加载请求时，首先并不会自己去尝试加载这个类，而是把这个请求委托给父类加载器去完成。
如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，直到启动类加载器（Bootstrap ClassLoader）。
当父类加载器无法完成类加载请求（例如未找到所需类）时，子加载器才会尝试自己去加载该类。
只有当父类加载器和本加载器均无法加载时，才会抛出ClassNotFoundException。

这种机制的主要优点在于保证了Java核心API类库不会被用户自定义的类所覆盖，同时也保证了类加载的统一性，防止了类的重复加载，有利于维护系统的稳定性和安全性。

5. HashMap原理

HashMap是Java编程语言中实现Map接口的一个重要类，它提供了键值对（key-value pairs）的高效存储和检索功能。以下是HashMap的主要原理概述：

数据结构：
- HashMap的核心数据结构是数组与链表或红黑树的结合体。在JDK 1.8及以后版本中，HashMap的每个桶（bucket）既可以是一个链表节点（Node）的集合，也可以在链表长度超过一定阈值（默认8）时转化为红黑树（以降低查询复杂度，提高性能）。
哈希函数：
- 当插入一个键值对时，首先计算key的哈希码（hashCode）。HashMap使用key的hashCode经过某种运算（例如二次哈希）得到在数组中的索引位置。
- 若有多个键拥有相同的哈希码（即发生了哈希冲突），它们会被存储在同一个桶中，通过链表或红黑树的方式连接在一起。
负载因子与扩容：
- 负载因子（load factor）是衡量HashMap满的程度的一个参数，默认值是0.75。当实际存储的键值对数量超过容量与负载因子的乘积时，HashMap会自动扩容，容量翻倍，并将所有的键值对重新哈希到新的数组中，这个过程叫做rehashing。
插入与查找过程：
- 插入过程：先计算key的哈希码并确定数组索引位置，然后将新的Entry（包含key-value对）添加到该索引位置对应的链表或红黑树头部（JDK1.7之前是尾部，1.8开始改为头部，提高了并发性能）。
- 查找过程：同样通过key的哈希码找到数组索引，然后遍历该索引位置上的链表或红黑树，比较每个节点的key是否相等，找到则返回相应的value。
线程安全性：
- HashMap本身是非线程安全的，这意味着在多线程环境下如果没有采取适当的同步措施，可能会出现并发问题。若需要线程安全的HashMap，可以使用ConcurrentHashMap。
迭代器行为：
- HashMap的迭代器在遍历时是弱一致性的，即迭代期间如果修改了HashMap，迭代器的行为是不确定的，可能抛出ConcurrentModificationException异常，也可能不会，取决于具体的修改时机和方式。

总之，HashMap利用哈希算法实现快速查找和插入，通过数组加链表（或红黑树）的方式来处理哈希冲突，以维持较高的性能和较低的空间消耗。

6. Java中实现多线程的方式

在Java中实现多线程主要有以下几种方式：

继承 java.lang.Thread 类：
- 创建一个新类，让它继承自 Thread 类。
- 重写 Thread 类的 run() 方法，这个方法包含线程需要执行的任务。
- 创建这个自定义线程类的实例，并调用其 start() 方法来启动线程。

public class MyThread extends Thread {
    @Override
    public void run() {
        // 在这里编写线程需要执行的任务
    }

    public static void main(String[] args) {
        MyThread thread = new MyThread();
        thread.start(); // 启动线程
    }
}

实现 java.lang.Runnable 接口：
- 创建一个类，实现 Runnable 接口，并实现其中的 run() 方法。
- 创建 Thread 类的实例，将实现了 Runnable 接口的对象作为构造函数的参数传入。
- 调用 Thread 对象的 start() 方法启动线程。

public class RunnableTask implements Runnable {
    @Override
    public void run() {
        // 在这里编写线程需要执行的任务
    }

    public static void main(String[] args) {
        RunnableTask task = new RunnableTask();
        Thread thread = new Thread(task);
        thread.start(); // 启动线程
    }
}

使用 java.util.concurrent.Callable 接口：
- Callable 接口允许线程执行有返回值的任务，并且可以抛出异常。
- 结合 FutureTask 或 ExecutorService 使用，可以异步获取线程执行的结果。

import java.util.concurrent.Callable;
import java.util.concurrent.FutureTask;

public class CallableTask implements Callable<String> {
    @Override
    public String call() throws Exception {
        // 在这里编写线程需要执行的任务，并返回结果
        return "Callable Task Result";
    }

    public static void main(String[] args) throws ExecutionException, InterruptedException {
        CallableTask task = new CallableTask();
        FutureTask<String> futureTask = new FutureTask<>(task);
        Thread thread = new Thread(futureTask);
        thread.start();
        thread.join(); // 确保线程执行完

        // 获取线程执行结果
        String result = futureTask.get();
        System.out.println(result);
    }
}

另外，还可以通过 ExecutorService 和 ThreadPoolExecutor 等并发工具类来创建和管理线程池，更加高效地执行多线程任务：

import java.util.concurrent.*;

public class ThreadPoolExample {
    public static void main(String[] args) throws ExecutionException, InterruptedException {
        ExecutorService executor = Executors.newFixedThreadPool(5); // 创建固定大小的线程池

        Callable<String> task = new CallableTask();
        Future<String> future = executor.submit(task);

        // 关闭线程池（这里仅做演示，实际应用中可能需要优雅关闭）
        executor.shutdown();
        executor.awaitTermination(Long.MAX_VALUE, TimeUnit.NANOSECONDS);

        // 获取线程执行结果
        String result = future.get();
        System.out.println(result);
    }
}

总的来说，Java中实现多线程不仅可以直接通过继承Thread类或实现Runnable接口来创建线程，还可以通过使用并发框架提供的高级接口如Callable和FutureTask来实现具有返回值的多线程任务，同时结合线程池管理来提高并发效率和资源利用率。

7. 线程池数量参数设置一般怎么设

线程池参数主要包括以下几个方面：

核心线程数（corePoolSize）：
- 表示线程池的基本规模，即使在没有任务执行时，线程池也会维持这么多线程数量。当线程池中有空闲线程时，新提交的任务会优先分配给这些空闲线程执行。
- 对于CPU密集型任务，核心线程数通常设置为与CPU核心数相同，这样可以充分利用CPU资源，同时避免过多线程引起上下文切换带来的开销。
- 对于IO密集型任务，因为线程在等待IO时CPU是空闲的，可以设置为核心线程数等于CPU核心数的2倍，以便在IO等待期间其他线程能继续执行任务，提高CPU利用率。
最大线程数（maximumPoolSize）：
- 表示线程池能够容纳的最大线程数量。当核心线程都在忙碌，且任务队列已满时，线程池会创建新的线程来处理任务，直到线程总数达到最大线程数为止。
- 对于CPU密集型任务，最大线程数通常设为CPU核心数 + 1，留有一定的余量应对突发任务，但不宜过高，否则会导致线程上下文切换过于频繁，反而降低整体性能。
- 对于IO密集型任务，最大线程数可以设得更高，但仍要考虑系统资源约束，避免过度竞争导致性能下降。
线程空闲存活时间（keepAliveTime）：
- 当线程池中的线程数量超过核心线程数时，多余的空闲线程在等待新任务到来的时间超过指定的keepAliveTime后，将会被终止。
- 设置合适的空闲存活时间有助于资源回收，尤其是在负载变化较大的场景中。
线程工厂（threadFactory）：
- 用于创建新线程的工厂，可以自定义线程的命名、优先级等属性。
任务队列（BlockingQueue workQueue） ：
- 用于存储待执行任务的队列，可以选择不同的队列类型，如无界的LinkedBlockingQueue、有界的ArrayBlockingQueue等。
- 任务队列的类型和大小也会影响线程池的线程数量设置。如使用无界队列，线程池在任务不断涌入时可能会迅速创建大量线程直至达到最大线程数，反之，有界队列则会在队列满后触发创建更多线程（如果还没有达到最大线程数的话）。
拒绝策略（RejectedExecutionHandler）：
- 当线程池和任务队列都满了，无法再接受新任务时，需要通过拒绝策略来决定如何处理新提交的任务。Java内置了几种拒绝策略，如AbortPolicy（抛出异常）、CallerRunsPolicy（调用者线程执行）、DiscardPolicy（丢弃任务）和DiscardOldestPolicy（丢弃队列中最旧的任务）。

配置线程池时，需要综合考虑系统资源、任务性质（CPU密集型或IO密集型）、任务执行时间等因素来合理设置这些参数，确保既能有效利用系统资源，又能满足任务处理的需求。同时，还可以根据实际需求自定义线程工厂和拒绝策略，增强线程池的功能和灵活性。

CPU密集型任务跟 IO密集型任务如何区分

CPU密集型任务和IO密集型任务的区分主要依据任务执行过程中的资源使用特征和瓶颈所在：

CPU密集型任务（CPU-bound）：

特点：
- 任务执行过程中，大部分时间花费在计算、逻辑处理和其他CPU密集型操作上，如数学运算、加密解密、图形渲染、大规模数据分析等。
- CPU使用率高，常常接近或达到100%。
- 对内存和硬盘IO速度要求相对较低，任务能否快速完成主要依赖于CPU的计算能力。
- 利用多核处理器并行计算可以显著提升任务处理速度。

IO密集型任务（IO-bound）：

特点：
- 任务执行过程中，大部分时间处于等待状态，如等待磁盘读写、网络传输、数据库查询等外部输入输出操作完成。
- CPU使用率相对较低，通常在IO操作等待期间，CPU可能处于闲置状态。
- 对内存和硬盘IO速度、网络带宽等资源要求较高，任务执行速度受限于IO设备的吞吐能力。
- 通过异步IO、多线程并发处理、减少不必要的IO操作、缓存策略等方式可以有效提高IO密集型任务的执行效率。

简而言之，CPU密集型任务主要是靠CPU计算能力推动任务进展，而IO密集型任务则是受限于外部设备的读写速度。在系统设计和优化时，识别任务的类型非常重要，因为针对不同类型的任务需要采取不同的优化策略。例如，对于CPU密集型任务，增加处理器核心数量或改进算法可提高性能；而对于IO密集型任务，改善IO设备性能、采用异步非阻塞IO模式和优化数据流管道等方法更为有效。

8. Runnable和Callable区别

Runnable和Callable是Java中两种不同的接口，它们都用于实现多线程，但在功能和使用上有以下显著区别：

目的和方法签名：
- Runnable: Runnable接口定义了一个单一的void run()方法，表示线程应该执行的任务。它没有返回值，也不能抛出受检异常。
- Callable: Callable接口定义了一个V call()方法，此方法可以有返回值（V代表任意类型），并且可以抛出受检异常。
返回结果：
- Runnable: Runnable的run()方法执行完毕后，无法直接获得任何执行结果。
- Callable: Callable的call()方法执行完毕后，会返回一个结果。这个结果可以通过Future对象来获取。
异常处理：
- Runnable: Runnable的run()方法内部必须自行处理所有异常，或者封装在RuntimeException中抛出。
- Callable: Callable的call()方法可以抛出任何受检异常，调用方可以捕获并处理这些异常。
Future和ExecutorService：
- Runnable: 若要获取Runnable执行的最终状态或结果，通常需要借助于FutureTask包装，然后通过ExecutorService提交执行。
- Callable: Callable可以直接通过ExecutorService的submit(Callable)方法提交执行，并立即获得一个Future对象，该对象可以用来获取call()方法的返回值，检查任务是否已完成，取消任务等。

举例说明：

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class Example {

    public static void main(String[] args) throws ExecutionException, InterruptedException {
        ExecutorService executor = Executors.newSingleThreadExecutor();

        // Runnable 示例
        Runnable task1 = () -> { /* 实现任务 */ };
        executor.execute(task1); // Runnable 直接执行，无法获取结果

        // Callable 示例
        Callable<Integer> task2 = () -> {
            int result = someComputation(); // 假设这是一个耗时计算
            return result;
        };

        Future<Integer> future = executor.submit(task2);
        Integer resultFromCallable = future.get(); // 获取Callable任务的执行结果

        executor.shutdown(); // 关闭线程池
    }

    private static int someComputation() {
        // ...
    }
}

综上所述，当你需要在线程执行完毕后获取一个明确的结果或者需要抛出并处理受检异常时，应选择使用Callable接口。而如果只是执行一个无需返回结果的操作，则可以使用Runnable接口。

9. Java线程怎么得到执行结果

在Java中，如果你想要获取线程执行的结果，可以使用Future或者Callable接口，具体的方法如下：

使用Callable和Future：

import java.util.concurrent.Callable;
import java.util.concurrent.FutureTask;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class CallableExample {
    public static void main(String[] args) throws ExecutionException, InterruptedException {
        // 创建一个Callable任务
        Callable<Integer> callableTask = () -> {
            int result = someComputation(); // 假设这是计算结果
            return result;
        };

        // 将Callable任务封装到FutureTask中
        FutureTask<Integer> futureTask = new FutureTask<>(callableTask);

        // 创建线程并执行任务
        Thread thread = new Thread(futureTask);
        thread.start();

        // 主线程等待FutureTask执行完毕并获取结果
        Integer result = futureTask.get(); // 这里会阻塞，直到Callable任务执行完成并返回结果
        System.out.println("Result from the Callable: " + result);
    }

    private static int someComputation() {
        // 这里是耗时计算或其他任务
        return 42; // 返回一个示例结果
    }
}

或者，你也可以通过ExecutorService来提交Callable任务并获取Future：

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class CallableWithExecutor {
    public static void main(String[] args) throws ExecutionException, InterruptedException {
        ExecutorService executor = Executors.newSingleThreadExecutor();

        // 创建Callable任务
        Callable<Integer> callableTask = () -> {
            int result = someComputation();
            return result;
        };

        // 提交任务到ExecutorService
        Future<Integer> future = executor.submit(callableTask);

        // 关闭ExecutorService（此处仅为示例，真实环境中请根据应用场景决定何时关闭）
        executor.shutdown();
        executor.awaitTermination(Long.MAX_VALUE, TimeUnit.NANOSECONDS);

        // 获取执行结果
        Integer result = future.get();
        System.out.println("Result from the Callable with Executor: " + result);
    }

    private static int someComputation() {
        // ...
    }
}

使用Future接口：
Future接口提供了获取异步计算结果的方法，你可以通过get()方法阻塞等待结果，或者使用isDone()检查任务是否已经完成。如果任务抛出了异常，get()方法还会重新抛出异常。
不推荐的方式：Thread.sleep()和共享变量：
一种不太推荐的做法是通过让主线程休眠一段时间，然后查看共享变量来间接获取结果。这种方式不稳定，因为很难准确估计任务执行完成的时间，容易造成死锁或资源浪费。

public class ThreadExample {
    private static volatile int sharedResult;

    public static void main(String[] args) throws InterruptedException {
        Thread thread = new Thread(() -> {
            sharedResult = someComputation();
        });
        thread.start();
        // 不推荐的做法：假设任务最多需要1秒完成
        Thread.sleep(1000);
        System.out.println("Assumed result: " + sharedResult);
    }

    private static int someComputation() {
        // ...
    }
}

建议尽量使用Callable和Future来确保正确、可靠地获取线程执行的结果。

10. CAS（Compare and Swap）原子操作

CAS（Compare and Swap，比较并交换）是一种原子操作，它是现代计算机硬件提供的一种底层原语级别的指令，广泛应用于多线程编程和并发控制中，用于实现无锁数据结构和算法。CAS操作包含三个操作数：

内存位置（或称为变量的内存地址）：它指向需要进行原子操作的变量。
预期值（旧值）：这个值是我们希望当前内存位置存储的值，CAS操作会检查内存位置的实际值是否与此预期值相等。
新值：如果内存位置的值与预期值相等，则将内存位置的值更新为此新值。

CAS操作的过程如下：

首先，它会检查内存位置的当前值是否等于预期值。
如果当前值与预期值相等，则将内存位置的值更新为新值。
如果当前值与预期值不相等，则不做任何修改，并且CAS操作失败（返回false或特定的错误码）。

在Java等高级编程语言中，通常通过JDK提供的原子类（如AtomicInteger、AtomicLong等）或Unsafe类的CAS方法（如compareAndSet）来利用CAS指令实现线程安全的无锁更新操作。在多线程环境下，CAS可以有效地避免多个线程同时修改同一变量时产生的竞态条件（race condition），并且在大多数情况下比传统的加锁机制更高效，因为它避免了线程之间的上下文切换和锁的争抢开销。

然而，CAS操作也不是万能的解决方案，它可能会遇到ABA问题（一个值被两次改回原来值的情形）以及其他一些并发问题，针对这些问题，有些数据结构采用了版本号或额外标记位等方法来解决。

11. Spring的核心注解、组成、过程

Spring框架的核心注解主要用于简化配置和促进依赖注入，使得开发者可以通过注解而非XML配置文件来组织和管理bean。以下是Spring框架中的一些核心注解以及它们在IoC容器中的作用和组成：

核心注解：

@Component：
- 用于标记一个类作为Spring容器管理的Bean。它是所有受Spring管理组件的基类注解，衍生出了@Service、@Repository和@Controller注解，分别对应业务层、数据访问层和控制层的组件。
@Configuration：
- 表明一个类是一个配置类，可以包含@Bean注解的方法来定义Spring容器中的Bean。配置类相当于一个或多个XML配置文件。
@Bean：
- 在@Configuration类的方法上使用，指示该方法返回的对象将作为一个Bean注册到Spring容器中。
@Autowired：
- 自动装配注解，Spring容器会自动寻找匹配的Bean，并将其注入到目标对象的字段、构造器或方法参数中。它可以作用于字段、方法或构造器。
@Qualifier：
- 当存在多个相同类型的Bean时，与@Autowired一起使用，用于指定注入哪个具体的Bean。
@Value：
- 用于在字段或方法/构造器参数级别注入属性值，可以从属性文件或SpEL表达式中读取。
@Scope：
- 定义Bean的作用域，例如singleton（单例，默认）、prototype（原型）、request、session等。

组成与过程：

Spring框架的核心流程主要包括：

组件扫描（Component Scan）：
- 通过@ComponentScan注解或XML配置告诉Spring在哪里搜索带有@Component及其衍生注解的类，并将它们自动注册到IoC容器中。
依赖注入（Dependency Injection, DI）：
- 通过@Autowired注解或其他依赖注入相关的注解，Spring容器在构建Bean实例时，会自动处理类之间的依赖关系，将依赖的Bean注入到目标Bean中。
Bean的生命周期管理：
- Spring容器负责创建Bean实例、初始化Bean（如果有@PostConstruct注解的方法）以及在适当的时候销毁Bean（如果有@PreDestroy注解的方法）。
基于注解的AOP（面向切面编程）：
- Spring还提供了诸如@Aspect、@Before、@After、@Around等注解，用于定义切面和通知，实现面向切面的编程。

综上所述，Spring框架的核心注解通过简化配置和实现自动化依赖注入，极大地提升了开发效率和代码的可维护性。通过一系列注解的组合运用，开发者能够轻松地构建起复杂的组件间关系和事务处理流程。

12. Spring开发常用工具类

在Spring框架及其生态中，有许多常用的工具类，它们在开发过程中提供了便利的功能。以下列举了一些Spring开发中常用的工具类及其用途：

org.springframework.util.StringUtils
- 提供了一组字符串操作方法，如空串检查、字符串连接、trim、equalsIgnoreWhitespace等，用于简化字符串处理工作。
org.springframework.beans.factory.BeanFactoryUtils
- 提供了与Spring BeanFactory交互的工具方法，例如查找Bean的别名、查找Bean的依赖等。
org.springframework.core.io.Resource
- 代表一个可以读写的资源对象，如文件、URL、类路径资源等，ClassPathResource和FileSystemResource是常见的实现类。
org.springframework.core.env.Environment
- 提供了获取和操作环境属性的方法，包括从属性源中读取配置信息。
org.springframework.core.convert.ConversionService
- 提供类型转换服务，帮助将一个对象转换为另一种类型。
org.springframework.util.Assert
- 断言工具类，用于在代码中进行条件检查，如果不满足条件则抛出异常。
org.springframework.beans.BeanUtils
- 提供了JavaBean之间属性复制和转换的方法，如copyProperties。
org.springframework.util.ConcurrentReferenceHashMap
- 提供了一种线程安全且具有弱引用和软引用功能的HashMap实现。
org.springframework.web.bind.annotation.RequestMappingAdviceAdapter
- Spring MVC中用于处理@RequestMapping注解的适配器，虽然不是工具类，但作为处理器映射和方法适配的重要组件，对于Web开发非常重要。
org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor
- 提供了基于Java线程池的异步任务执行器，可用于处理异步任务。
org.springframework.data.util.Streamable
- 在Spring Data中，提供了一种类似Java 8 Stream API的工具类，用于简化集合操作。
org.springframework.util.ConcurrentReferenceHashMap
- 并发友好且带有弱引用或软引用功能的HashMap实现，用于解决特定场景下的内存管理问题。

此外，Spring Boot也提供了许多便捷工具类，如org.springframework.boot.SpringApplication用于启动Spring Boot应用，org.springframework.boot.context.properties.ConfigurationProperties用于绑定外部配置到Bean属性等。

13. Spring开发中异常处理

在Spring框架开发中，异常处理是非常重要的一部分，它可以帮助开发者对应用程序中的错误进行统一处理，向客户端返回有意义的错误信息，同时保持代码整洁。以下是在Spring中处理异常的几种常见方式：

使用@ControllerAdvice和@ExceptionHandler注解：

@ControllerAdvice是一个全局异常处理注解，它可以应用到一个类上，使得该类中的异常处理方法适用于所有的@RequestMapping注解的方法。
@ExceptionHandler注解用于在一个方法上，声明该方法可以处理某种特定类型的异常。当控制器方法抛出异常时，Spring会查找具有相应@ExceptionHandler注解的方法来处理异常。

示例：

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(value = IllegalArgumentException.class)
    @ResponseBody
    public ResponseEntity<String> handleIllegalArgumentException(IllegalArgumentException ex) {
        // 处理并返回自定义响应
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(ex.getMessage());
    }

    // 其他异常处理方法...
}

实现ErrorController接口：

Spring Boot提供了ErrorController接口，允许自定义 /error 请求映射的处理逻辑。当发生未被捕获的异常或者请求处理过程中出现了错误时，Spring Boot会将请求转发到 /error 地址，通过实现这个接口，你可以自定义错误页面或者返回错误信息。

示例：

@Controller
public class CustomErrorController implements ErrorController {

    @Override
    public String getErrorPath() {
        return "/error";
    }

    @RequestMapping("/error")
    public ModelAndView error(HttpServletRequest request) {
        // 获取异常信息
        Object status = request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE);
        ModelAndView modelAndView = new ModelAndView();
        if ((Integer) status == HttpStatus.NOT_FOUND.value()) {
            modelAndView.setViewName("404");
        } else {
            modelAndView.setViewName("500");
        }
        return modelAndView;
    }
}

扩展ResponseEntityExceptionHandler类：

Spring MVC提供了一个基础的异常处理器类ResponseEntityExceptionHandler，你可以通过扩展这个类并覆盖其中的方法来处理特定的异常类型。

示例：

@ControllerAdvice
public class CustomExceptionHandler extends ResponseEntityExceptionHandler {

    @Override
    protected ResponseEntity<Object> handleMethodArgumentNotValid(MethodArgumentNotValidException ex, HttpHeaders headers, HttpStatus status, WebRequest request) {
        // 自定义处理验证失败的异常
        return super.handleMethodArgumentNotValid(ex, headers, status, request);
    }

    // 其他重写方法以处理特定类型的异常...
}

全局异常处理器：
- 除了注解方式，还可以通过实现HandlerExceptionResolver接口或继承AbstractHandlerExceptionResolver类来实现全局异常处理逻辑，不过这种方式相较于注解更加繁琐，通常在注解不足以满足需求时使用。

通过上述方法，Spring框架提供了强大的异常处理机制。

14. Spring自动装配、两个注解区别

在Spring框架中，自动装配指的是Spring容器能够自动将Bean依赖关系注入到另一个Bean中，而不需要手动配置。主要涉及的两个注解是@Autowired和@Resource，它们都可以用于自动装配Bean的依赖项，但有一些关键区别：

`@Autowired`（Spring框架提供）

@Autowired注解由Spring框架提供，用于自动装配Bean之间的依赖关系。
默认情况下，@Autowired注解按照类型进行自动装配，也就是说，Spring容器会查找与目标字段或方法参数类型兼容的所有候选Bean，然后将其注入。
如果容器中存在多个与目标类型匹配的Bean，先按类型再按名称。
在自动装配时又没有显式指定Bean的名称或Qualifier，Spring会抛出异常，提示找不到唯一的匹配Bean。
可以通过在字段、setter方法或构造器参数上使用@Autowired注解，以实现自动装配。
可以结合@Qualifier注解，通过名称（或Qualifier的value）来精确指定需要装配的Bean。

`@Resource`（Java EE标准，Spring也支持）

@Resource注解来自于Java EE的标准JSR-250规范，但Spring也支持该注解进行自动装配。
@Resource注解默认按照名称（bean的ID或名称）来进行自动装配，而不是类型。这意味着如果在注解的字段或方法上指定了name属性（或默认使用字段名作为bean的名称），Spring将尝试按照名称查找并注入Bean。
当找不到与名称匹配的Bean时，@Resource才按照类型进行自动装配。
同样可以在字段、setter方法或构造器参数上使用@Resource注解进行自动装配。

总结起来，@Autowired注解更侧重于类型驱动的自动装配，而@Resource注解更倾向于名称驱动的自动装配。在Spring环境中，两者都可以用于自动装配，但在没有指定名称的情况下，它们的默认行为有所不同。

15. Spring MVC的过程

在这里插入图片描述 Spring MVC的工作流程可以细分为以下几个步骤：

客户端请求：
用户通过浏览器或其他客户端向服务器发送HTTP请求。
DispatcherServlet接收请求：
请求首先到达Spring MVC的核心入口——DispatcherServlet。在web.xml配置文件中，DispatcherServlet被映射到特定的URL模式，以便拦截相应的请求。
HandlerMapping：
DispatcherServlet通过查询一系列HandlerMapping实现（如RequestMappingHandlerMapping等），找到能够处理当前请求的处理器（Handler，通常是Controller中的一个方法）。
HandlerAdapter：
找到处理器后，DispatcherServlet通过对应的HandlerAdapter调用处理器执行请求处理逻辑。HandlerAdapter的作用是适配不同类型的处理器，使得DispatcherServlet可以统一处理多种类型的处理器。
Controller处理请求：
Controller执行业务逻辑，调用服务层方法，处理完业务后，通常会将数据封装到Model对象中，并决定下一步视图渲染逻辑。这可以是返回一个ModelAndView对象，或是通过注解（如@ResponseBody）直接返回数据。
视图解析：
如果Controller返回的是一个视图名（如一个字符串），DispatcherServlet会将请求转交给视图解析器（ViewResolver），视图解析器负责将视图名解析为实际的视图对象（如JSP、Thymeleaf模板、FreeMarker模板等）。
视图渲染：
视图对象根据Model中的数据渲染响应内容，并将渲染后的HTML等文本格式的数据返回给DispatcherServlet。
响应客户端：
DispatcherServlet将渲染好的响应内容发送回客户端，客户端（浏览器）接收到响应后，呈现给用户。
异常处理：
整个处理过程中，如果出现异常，Spring MVC可通过全局异常处理器（如使用@ControllerAdvice和@ExceptionHandler注解的类）捕获并处理异常，根据异常类型和配置生成对应的错误页面或错误信息返回给客户端。

以上就是Spring MVC处理HTTP请求的基本流程。在整个过程中，Spring MVC实现了MVC架构，分离了请求处理、业务逻辑处理和视图渲染等功能，增强了系统的可维护性和可扩展性。

16. 解决循环依赖的方法

循环依赖在软件工程中是一个常见的问题，特别是在依赖注入（Dependency Injection，DI）框架如Spring中尤为突出。循环依赖是指两个或多个对象之间相互依赖，形成一个闭环。例如，在Spring中，当两个Bean A和B彼此依赖时，即Bean A需要注入Bean B，而Bean B又反过来依赖Bean A，则构成循环依赖。解决循环依赖的方法有以下几种：

在Spring框架中的解决方案：

1. 单例Bean的循环依赖处理：

构造器注入的循环依赖不可解决：Spring无法自动解决由构造器注入造成的循环依赖，因为构造器的调用顺序不可改变，会导致死锁。
setter注入在单例模式下的循环依赖可解决：Spring容器通过三级缓存机制（EarlySingletonInitializationExceptionHolder、DefaultListableBeanFactory的singletonObjects、prototypeCurrentlyInCreation）来提前暴露部分初始化的单例bean，从而允许在另一个bean完成构造时注入已经存在的早期引用。

2. 代码层面的解决策略：

重构代码：从根本上解决循环依赖问题的最佳实践是重新设计系统架构和组件间的关系，确保依赖关系是单向或者树状结构而非环状。
使用方法注入代替字段注入：有时通过在某个生命周期方法（如初始化方法@PostConstruct）中注入依赖，而不是在字段级别注入，可以避免循环依赖的发生。
降低耦合度：提取公共部分为独立的服务或接口，减少直接的双向依赖。

三级缓存

Spring容器通过三级缓存机制来解决循环依赖的问题
Spring框架中解决单例Bean循环依赖问题的关键技术之一就是三级缓存机制。在Spring IoC容器中，当容器初始化Bean时，会使用三级缓存来处理循环依赖的情况。下面是三级缓存的详细描述：

一级缓存（singletonObjects）：
这是最主要的缓存，用于存储已经完全初始化好（包括构造器调用、属性填充和初始化方法调用等）的单例Bean实例。当其他Bean需要注入已存在于一级缓存中的Bean时，可以直接从一级缓存中获取并注入。
二级缓存（earlySingletonObjects）：
也被称为早期曝光对象缓存，用于存储那些已经实例化但还未完成初始化（属性注入尚未完成）的单例Bean。当Spring检测到循环依赖时，会将正在创建但尚未初始化完成的Bean实例提前放入二级缓存中，以便其他依赖于它的Bean可以先行注入这个早期曝光的对象引用。
三级缓存（singletonFactories）：
存储的是能够生产Bean实例的工厂对象，这些工厂对象通常是由ObjectFactory或ObjectProvider实现的。当Spring发现一个Bean正在创建并参与循环依赖时，会将其对应的工厂对象放入三级缓存中。当依赖于这个Bean的其他Bean需要注入时，Spring会通过工厂对象来获取并注入Bean实例，而不必等待目标Bean完全初始化完成。

在处理循环依赖的过程中，Spring首先会尝试从一级缓存中获取Bean，如果不存在则查看二级缓存，如果二级缓存中也没有，那么尝试从三级缓存中获取工厂对象来创建Bean实例。当循环依赖链条中的最后一个Bean完成初始化后，会将它移动到一级缓存中，同时清空二级缓存中对应的数据，保证了最终注入的Bean是完整的初始化状态。通过这种机制，Spring巧妙地解决了单例Bean之间的循环依赖问题。

示例

以下是一个简单的例子来说明Spring框架如何利用三级缓存解决单例Bean之间的循环依赖问题：

假设我们有两个单例Bean：BeanA和BeanB，它们互相依赖：

@Component
public class BeanA {
    private BeanB beanB;

    @Autowired
    public BeanA(BeanB beanB) {
        this.beanB = beanB;
    }
}

@Component
public class BeanB {
    private BeanA beanA;

    @Autowired
    public BeanB(BeanA beanA) {
        this.beanA = beanA;
    }
}

在这种情况下，Spring IoC容器在初始化BeanA时，发现它需要注入BeanB。在创建BeanB时，又发现BeanB需要注入BeanA，形成了循环依赖。

Spring解决这个问题的步骤如下：

容器开始初始化BeanA，在创建BeanA实例后，会将BeanA的半成品（已实例化但尚未完成属性注入的实例）放入二级缓存（earlySingletonObjects）。
然后容器开始初始化BeanB，在解析BeanB的构造器参数时发现需要注入BeanA。由于BeanA已经在创建过程中，所以容器会尝试从二级缓存中获取BeanA的半成品，并注入到BeanB中。
完成了BeanB的初始化之后，BeanB会被放入一级缓存（singletonObjects），表示它已经完全初始化完成。
最后，回到BeanA的初始化过程，由于BeanB已经初始化完成并放入一级缓存，容器可以从一级缓存中获取完整的BeanB实例并注入到BeanA中。
完成BeanA的所有初始化步骤后，将BeanA从二级缓存移动到一级缓存，并清除二级缓存中与BeanA相关的数据。

通过上述三级缓存的协调运作，Spring成功地打破了循环依赖，确保了两个Bean都能正确地初始化和注入。请注意，这个例子简化了Spring容器内部的复杂逻辑，实际的实现细节更为复杂。

17. MyBatis中$号和#号的区别

在MyBatis中，$ 和 #{} 符号在SQL语句中用于动态参数的占位符，它们的主要区别在于SQL预编译和类型安全及SQL注入防御方面的处理：

$ (美元符号)：
- $ 用于字符串替换，MyBatis在处理含有 $ 符号的参数时，会直接将参数值插入到SQL语句中，不做任何转义或类型转换处理。
- 由于 $ 直接拼接SQL字符串，因此不提供SQL注入防护。如果参数值未经充分过滤或验证，可能会产生SQL注入风险。
- $ 通常用于动态构造SQL的部分，比如动态表名、列名等，但使用时要特别小心，确保输入安全。
#{} (井号)：
- #{} 用于预编译参数占位符，MyBatis会将#{}包裹的参数替换为 JDBC 预编译语句（PreparedStatement）中的 ? 占位符，并在执行SQL时为其绑定适当的参数值。
- #{} 支持类型转换和SQL注入防护，MyBatis会自动根据参数类型对值进行处理，并确保在传入数据库之前对特殊字符进行了正确的转义，有效防止SQL注入攻击。
- #{} 适用于传递查询条件、插入或更新的值等，尤其在涉及到用户输入或不确定来源的数据时，推荐使用#{}以确保安全。

总结来说，$ 更适合处理静态或已知安全的内容，而 #{} 则用于处理动态参数并提供SQL注入保护。在实际应用中，除非确信输入是安全的，否则通常建议使用 #{} 以提高安全性。

18. MySQL数据库引擎及区别

当然可以，以下是MySQL存储引擎特点及适用场景整理成表格的形式：

存储引擎	特点	适用场景
InnoDB	- 默认存储引擎 - 支持事务处理（ACID特性） - 支持行级锁定和外键约束 - 支持MVCC，提高读写并发性能	- 写密集型应用 - 需要事务处理的场景
MyISAM	- 早期默认存储引擎 - 不支持事务和行级锁定 - 插入和查询速度快 - 只支持表级锁定 - 支持全文索引	- 只读或读多写少的场景 - 需要全文搜索的场景
MEMORY（HEAP）	- 数据存储在内存中 - 提供极快的访问速度 - 服务器重启或表关闭后数据丢失	- 存储临时的小型、只读或读多写少的数据表
Archive	- 用于大量插入和很少查询的场景 - 支持压缩，节省存储空间 - 只支持INSERT和SELECT操作，不支持删除和更新	- 归档和审计日志记录
CSV	- 数据存储为逗号分隔文本文件 - 适用于数据导出导入和与其他应用程序的数据交换	- 数据迁移、交换
MariaDB的XtraDB	- InnoDB高性能变体 - 提高并发性、恢复速度等	- 高性能、高并发应用场景
BLACKHOLE	- 不存储任何数据，忽略写入操作 - 对所有SELECT操作返回空结果	- 数据复制的中间环节或日志记录

在实际应用中，根据项目需求、数据的一致性要求、并发性能需求以及数据备份恢复策略等方面，选择最合适的存储引擎。

19. 四种隔离级别

MySQL数据库中的四种事务隔离级别是为了确保在并发事务处理时的数据一致性，它们分别是：

读未提交（Read Uncommitted）：
- 在这种级别下，一个事务可以看到其他事务未提交（Uncommitted）的数据变更。这意味着如果另一个事务随后回滚，那么当前事务读取的数据可能是不一致的，也就是“脏读”（Dirty Read）现象可能发生。
读已提交（Read Committed）：
- 在这个级别，一个事务只能看到已经提交（Committed）的数据。每次读取都会看到事务开始以来已经提交的最新数据。这可以防止脏读，但可能导致“不可重复读”（Non-repeatable Read），即在同一事务内，两次执行相同的查询可能会得到不同的结果，因为在这两次查询之间，有其他事务提交了对相关数据的修改。
可重复读（Repeatable Read）：
- 这是MySQL的默认事务隔离级别。在该级别，事务在开始至结束期间，对同一份数据的多次读取都将返回第一次读取时的状态，即使其他事务在这期间提交了对这些数据的修改。换句话说，事务在其执行期间看到的数据集是固定的，不会看到其他事务的中间状态。然而，尽管不可重复读得到了解决，但“幻读”（Phantom Read）仍然是可能的，即在同一个事务内，前后两次执行同样的范围查询可能会返回不同的行数，因为其他事务插入了新的行。
串行化（Serializable）：
- 这是最高级别的隔离级别，它通过在读取数据时加更多的锁来完全避免脏读、不可重复读和幻读。在该级别下，事务执行的效果如同事务按顺序串行执行一样，虽然提供了最强的一致性保障，但也可能导致严重的并发性能下降，因为事务之间需要等待彼此释放锁才能继续执行。

每种隔离级别都是在牺牲一定并发性能的基础上提高数据一致性，实际应用中需要根据业务场景权衡并发性和数据完整性之间的关系来选择合适的隔离级别。

20. 索引的分类

索引在数据库中是用来加速查询性能的重要数据结构，根据不同的分类方式，索引可以分为以下几种类型：

根据索引的逻辑功能分类：
- 普通索引（Basic Index / Simple Index）：最基本的索引类型，仅仅加快查询速度，没有任何附加限制。
- 唯一索引（Unique Index）：索引列的值必须是唯一的，不能有重复，除了加速查询，还能保证数据的唯一性。
- 主键索引（Primary Key Index）：特殊的唯一索引，每个表只能有一个，用于标识每一行记录的唯一性，不能为空。
- 全文索引（Full-text Index）：用于对文本型字段进行全文检索，支持对文本中的关键字进行模糊查询。
- 空间索引（Spatial Index）：适用于地理空间数据类型的索引，用于处理地理坐标点或空间对象的查询。
根据索引所作用的字段数目分类：
- 单列索引（Single Column Index）：索引基于单个字段创建。
- 复合索引（Composite/Index/Multi-column Index）：基于多个字段组合创建的索引，查询时遵循最左前缀匹配原则。
根据索引的物理实现方式分类：
- B-Tree索引（B-tree Index）：广泛使用的索引类型，数据按照B树结构组织，MySQL和其他数据库系统普遍支持。
- 哈希索引（Hash Index）：基于哈希表实现，MySQL的InnoDB引擎在特定条件下支持哈希索引，如内存表。
- R-Tree索引（R-tree Index）：主要用于空间索引，适合多维数据的索引，MySQL的空间数据类型支持R-Tree索引。
- 全文索引（Full-text Index）：基于倒排索引实现，用于全文检索。
根据索引和数据存储的位置关系分类：
- 聚簇索引（Clustered Index）：索引的叶节点直接存放表的行数据，主键索引在InnoDB引擎中默认是聚簇索引，表数据按照索引顺序物理存储。
- 非聚簇索引（Non-clustered Index）：索引与数据分开存储，索引包含了指向表数据行的指针，主键之外的索引在InnoDB中通常是非聚簇索引。
其他分类：
- 前缀索引（Prefix Index）：基于列的前几个字符创建的索引，可以减少索引大小，但牺牲了部分查询准确性。
- 覆盖索引（Covering Index）：索引中包含了查询需要的所有列，可以直接从索引中获取查询结果，无需回表查询。

在实际应用中，选择合适的索引类型和结构取决于具体的业务需求、查询模式以及数据库管理系统本身的支持程度。

21. 慢查询优化方法

慢查询优化是数据库性能优化的重要组成部分，下面列出了一些常见的慢查询优化方法：

分析查询语句：
- 使用EXPLAIN或EXPLAIN ANALYZE命令分析SQL执行计划，查看是否存在全表扫描、索引未使用或排序消耗较大的情况。
索引优化：
- 添加缺失的索引：如果查询中频繁出现在WHERE子句、JOIN条件、ORDER BY、GROUP BY等部分的列没有索引，考虑为其添加合适的索引。
- 优化索引使用：检查现有索引是否合理，避免冗余索引，调整复合索引的列顺序以适应查询需求，考虑使用覆盖索引以减少回表操作。
- 删除不必要的索引：过多的索引会占用存储空间，并在插入、更新操作时影响性能，删除不常使用或冗余的索引。
查询优化：
- 减少查询的复杂度：尽量避免在查询中使用子查询，尝试将其转换为JOIN操作或临时表。
- 避免全表扫描：确保查询条件能利用索引，尤其是WHERE子句中的条件。
- 避免排序和临时表：如果查询需要排序大量数据，考虑优化查询逻辑或添加索引来避免排序操作。尽量减少使用DISTINCT和GROUP BY带来的临时表创建。
- 减少数据传输量：只返回需要的字段，避免SELECT *，并通过JOIN条件和WHERE子句精确筛选数据。
SQL语句优化：
- 避免在索引列上进行函数运算或类型转换，这可能导致索引失效。
- 使用IN操作符替代OR操作符，提高查询效率。
- 对于批量数据操作，尽量使用批量插入、更新和删除操作，减少网络通信开销和数据库事务次数。
数据库结构优化：
- 数据库表设计合理化：根据业务需求合理划分表，避免过度范式化或反范式化导致的性能问题。
- 数据类型优化：选择合适的数据类型，减小字段长度，合理设置字段是否可为空等。
硬件和系统参数优化：
- 增加内存：增大数据库服务器的内存可以提升缓存命中率，减少磁盘I/O。
- 调整数据库参数：根据实际情况调整缓冲区大小、连接数、日志缓冲区、事务隔离级别等数据库系统参数。
监控和分析：
- 使用数据库性能监控工具定期查看慢查询日志，定位性能瓶颈。
- 对数据库负载进行性能测试，模拟真实环境下的压力，找出潜在的问题。
读写分离与分库分表：
- 对于读多写少的应用场景，可以采用读写分离策略减轻主库压力。
- 当数据量过大时，考虑采用分库分表策略，将数据分散在多个数据库或表中，降低单表的压力。

总的来说，慢查询优化是一项综合性的工作，需要从SQL语句、索引设计、数据库结构、硬件配置等多个维度进行深入分析和优化。

22. Redis数据类型

Redis是一个键值存储系统，支持多种数据结构作为其值类型，这些数据类型使得Redis不仅仅是一个简单的键值存储，还具备丰富的数据操作功能。以下是Redis支持的主要数据类型：

String（字符串）：
- Redis的字符串可以存储任何类型的数据，包括字符串、数字（整数和浮点数）、甚至是序列化的对象。支持多种操作，如GET、SET、INCR、DECR等。
List（列表）：
- Redis列表是链表数据结构，可以存储多个有序的字符串元素。支持LPUSH、RPUSH（在头部或尾部添加元素）、LPOP、RPOP（从头部或尾部弹出元素）、LRANGE（获取指定范围内的元素）等操作。
Set（集合）：
- Redis集合中的元素是无序且唯一的，支持SADD（添加元素）、SMEMBERS（获取所有元素）、SISMEMBER（判断元素是否在集合中）、SREM（移除元素）等操作。
Sorted Set（有序集合）：
- Redis有序集合中的成员是唯一的，同时每个成员都有一个分数（score），成员按照分数进行排序。支持ZRANGE（获取指定范围内的成员）、ZADD（添加元素并指定分数）、ZREVRANGE（逆序获取指定范围内的成员）等操作。
Hash（哈希）：
- Redis哈希是一个键值对的集合，键值对的值也是字符串类型。支持HSET（设置哈希字段的值）、HGET（获取哈希字段的值）、HMSET/HMGET（批量设置或获取多个字段值）、HDEL（删除哈希中的字段）等操作。
Bitmaps（位图）：
- 虽然不是严格意义上的数据类型，但Redis支持位数组操作，可以高效地处理位级别的数据。如SETBIT、GETBIT等操作。
HyperLogLog：
- HyperLogLog结构可以近似统计集合中不重复元素的数量，占用较小的内存空间，精度随着元素数量的增多而逐渐逼近实际值。支持PFADD（添加元素）、PFCOUNT（统计不重复元素数量）等操作。
Geospatial indexes（地理位置索引）：
- Redis支持对地理位置信息进行存储和操作，如GEOADD（添加地理位置信息）、GEORADIUS（查询指定范围内的地理位置）等。
Streams（流）：
- Redis 5.0引入的流数据类型，支持多条消息按顺序存储，并且可以跟踪消费者消费消息的状态。支持XADD（添加消息）、XREAD/XREADGROUP（读取消息）等操作。

每种数据类型都有其特定的API和适用场景，可以根据应用程序的需求选择合适的数据类型。

23. Redis持久化机制

Redis是一种内存数据库，但它提供了两种持久化机制，以确保在服务器重启后能够恢复数据，这两种机制分别是RDB（Redis Database）和AOF（Append Only File）。

RDB持久化：
- RDB是Redis的默认持久化方式，它通过在指定的时间间隔内将内存中的数据生成一份或多份数据快照（Snapshot）保存到磁盘上。
  - 优点：
    - 文件紧凑，易于备份。
    - 恢复时速度较快。
  - 缺点：
    - 如果在持久化之前Redis意外宕机，最后一次生成快照到宕机期间的数据将会丢失。
    - 由于RDB是定时触发或满足某些条件（如修改次数）时生成，所以数据的持久化有一定的滞后性。
AOF持久化：
- AOF持久化是将每一次写操作以命令的形式追加到AOF（Append Only File）文件的末尾，当Redis重启时，会重新执行AOF文件中的命令来恢复数据。
  - 有三种不同的写回策略（appendfsync）：
    - always：每次写操作都会同步到磁盘，数据安全，但性能较低。
    - everysec：默认策略，大约每秒同步一次，兼顾性能与安全性。
    - no：操作系统决定何时同步到磁盘，性能最好，但数据安全性最低。
  - 优点：
    - 数据安全性更高，几乎能做到实时持久化。
    - 可以通过配置文件设置不同的持久化粒度，最小损失是单条命令。
  - 缺点：
    - 随着操作的增多，AOF文件会越来越大，需要定期通过BGREWRITEAOF命令对其进行重写，压缩文件体积。
    - 恢复时由于需要逐条执行AOF文件中的命令，相对于RDB恢复速度较慢。

Redis 4.0及以后版本引入了混合持久化（AOF+RDB），在AOF重写时，可以选择将当前内存数据以RDB格式写入AOF文件开头，进一步优化了重启恢复速度。

在实际使用中，开发者可以根据应用场景选择单独使用RDB、AOF或二者结合的方式进行持久化，以达到数据安全性和性能的最佳平衡。

24. 常用的持久化方式

在Redis中，常用的持久化方式主要有两种：

RDB (Redis Database)：
- RDB持久化是通过在特定时间点将Redis内存中的所有数据生成一个数据集的二进制快照（snapshot）并将其保存到磁盘上。这些快照文件通常命名为dump.rdb。触发RDB持久化可以是按照配置文件中预设的规则自动进行，也可以由管理员手动执行SAVE或BGSAVE命令触发。
- RDB的特点是恢复速度快，文件占用空间相对较小，但由于其是周期性的快照，如果在两次持久化之间Redis服务器宕机，则在这段时间内的数据更新可能会丢失。
AOF (Append Only File)：
- AOF持久化则是记录每一次对Redis服务器的写操作，将这些操作以命令的形式追加到AOF日志文件中。在Redis重启时，会重新执行AOF文件中的所有命令来恢复数据到最新状态。
- AOF持久化可以配置不同的同步策略以平衡数据安全性和性能。例如，可以选择每个命令立刻同步到磁盘（appendfsync always），每秒同步一次（appendfsync everysec，这是默认选项），或者让操作系统自行决定何时同步（appendfsync no）。
- AOF相比RDB的优点在于数据丢失的可能性更小，因为它是实时或接近实时地记录所有写操作，但这也导致AOF文件可能随着操作的增加而变得越来越大，因此Redis包含了一个AOF重写机制，用来压缩AOF文件的体积。

综合考量，Redis允许用户根据应用程序的需求和场景灵活选择和配置持久化策略，甚至可以同时开启RDB和AOF持久化，形成所谓的“混合持久化”，从而兼得两者的优势。

25. Redis为什么设计成单线程

Redis被设计成单线程模型的主要原因是：

内存操作快速: Redis是一个基于内存存储的数据结构服务器，大部分操作都在内存中完成，内存的访问速度非常快，几乎不存在延迟问题，因此CPU往往不会成为Redis性能的瓶颈。
避免锁竞争: 在多线程环境中，为了保证数据一致性，通常需要使用锁进行资源保护，这会导致线程间的上下文切换以及锁竞争带来的开销。而Redis作为单线程模型，所有的操作序列化执行，无需考虑并发控制，简化了数据结构的设计与实现，并且消除了因锁造成的性能损失。
I/O模型高效: Redis利用了多路复用（Multiplexing）技术，如epoll (Linux) 或者 kqueue (BSD/MacOS)，在一个线程内高效处理大量并发连接请求，即便在网络I/O阻塞时，也能保证其他客户端请求能够继续得到响应，这样极大地提升了系统的并发能力。
设计简洁性: 单线程设计使得Redis代码更加简洁，易于维护和优化。同时也降低了编程复杂度，减少了出错的概率。
横向扩展: 当单台服务器的处理能力不足时，可以通过分布式部署的方式，在多台服务器上启动多个Redis实例，利用Redis Cluster或其他分片技术来进行水平扩展，而不是通过增加多线程的方式进行纵向扩展。

总之，Redis在设计之初就定位为高性能的内存数据库，单线程模式使其能够在处理大部分常见场景时达到较高的吞吐量，同时保持较低的延迟，而潜在的性能瓶颈则通过提升硬件配置（如增加内存和使用更快的网络设备）、优化数据结构、使用高效的I/O模型以及横向扩展集群来解决。

26. 实现Redis一致性的方法

Redis作为一款基于内存的键值存储系统，在分布式环境下的数据一致性主要通过以下几种方法来实现：

主从复制（Replication）：
Redis提供了主从复制功能，主节点（Master）的写操作会被复制到从节点（Slave）。通过配置一主多从，主节点写入的数据会异步或半同步复制到从节点，确保数据在多个节点间保持一致。为了增强数据安全性，可以配置成主从+哨兵（Sentinel）模式，哨兵能够监控主从节点的状态，并在主节点故障时自动完成主备切换。
Redis Cluster：
Redis Cluster实现了分布式数据分区（Sharding），每个节点都是主节点，负责一部分数据。Cluster通过数据分片（Partitioning）和槽（Slot）的概念，保证数据均匀分布到各个节点，并且通过 gossip 协议传播节点状态信息，当一个节点失效时，客户端能够自动重定向请求到正确的节点上。另外，Cluster还支持跨多个主从节点的故障转移，以保持数据的高可用性。
事务（Transactions）：
Redis支持事务处理，通过MULTI、EXEC、WATCH等命令实现一组命令的原子执行，确保在并发环境下的一致性。然而，需要注意的是，Redis的事务并不能提供ACID中的隔离性，因为在执行事务的期间，其他客户端仍然可以对数据进行操作。
发布/订阅（Publish/Subscribe）：
发布/订阅模式可用于实现事件驱动的数据同步，当某个键发生变化时，可以触发一个消息发布到指定频道，订阅该频道的客户端会收到通知并执行相应更新操作，以此间接保证数据一致性。
Lua脚本：
Redis支持在服务器端运行Lua脚本，通过eval或evalsha命令可以将一系列操作打包成一个原子执行单元，避免在多客户端操作时可能出现的数据不一致问题。
持久化策略：
虽然这不是严格意义上的分布式一致性概念，但通过RDB和AOF两种持久化策略，Redis能够在重启后从磁盘恢复数据，确保内存数据与磁盘上的持久化数据保持一定程度的一致性。

在实际应用中，根据业务需求的不同，可能会结合使用上述多种方法来确保Redis在分布式环境中的数据一致性。对于强一致性需求，通常需要配合应用层的分布式锁、Redlock算法或者其他分布式协调服务（如ZooKeeper）共同实现。

27. Nacos和Eureka区别

特征/产品	Eureka	Nacos
服务发现原理	客户端拉取模型为主，服务端推送辅助	客户端拉取模型与服务端推送相结合，支持实时更新
服务健康检查	基于客户端心跳	客户端心跳 + 服务端主动探测（TCP、HTTP等）
服务治理功能	注册、续约、注销、剔除等基本功能	注册、发现、续约、注销等基本功能，以及配置管理、权重分配、服务分组、命名空间隔离等更丰富服务治理功能
一致性协议	最终一致性，自我保护模式，AP	支持CP/AP模式，可根据场景选择强一致或高可用优先
集成度	集成于Spring Cloud生态，偏向Java生态	支持多语言和框架，深度整合阿里巴巴云原生微服务解决方案
配置管理	不具备	内置配置中心，支持动态配置推送和灰度发布
生态	Spring Cloud官方推荐服务发现组件	阿里巴巴开源，广泛应用于云原生和服务治理场景

28. TEXT和CHAR的区别

在数据库中，TEXT 和 CHAR 是两种不同的数据类型，用于存储字符串数据，它们的主要区别在于存储容量、存储方式和性能特性：

存储容量：
- CHAR：固定长度的字符串类型，长度在创建表时预先指定，且长度范围有限制（通常在1到255个字符之间，根据不同数据库有不同的上限，例如MySQL中为255字节）。无论实际存储的字符串长度是多少，都会占用预先设定的长度空间，剩余空间通常会被填充空格（在某些数据库中可以自定义填充字符）。
- TEXT：变长的字符串类型，用于存储大量文本数据，可以存储远超过CHAR所能容纳的数据量。在MySQL中，TEXT类型有多种大小规格，例如TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT，最大长度从255个字符到约4GB不等。
存储方式：
- CHAR：存储时会在物理空间上连续存储，且由于是定长，所以存储效率较高，查询时可以直接定位到数据位置。
- TEXT：存储时可能不会像CHAR那样连续存储，特别是当文本内容很长时，数据库可能将其存储在专门的区域，甚至单独的存储块上。对于非常大的文本内容，TEXT类型可能会使用更复杂的存储机制，如使用指针指向实际数据存储位置。
性能和索引：
- CHAR：由于是定长，CHAR类型字段在排序和创建索引时效率较高，但额外填充的空格可能会浪费存储空间。
- TEXT：由于是变长，TEXT类型字段不适合作为排序或索引的依据，尤其是在TEXT字段很大的情况下，数据库通常不允许在其上建立全文索引，但可以建立前缀索引。查询时，TEXT字段内容的比较和检索通常比CHAR字段慢。
使用场景：
- CHAR：适用于存储长度固定且相对较短的字符串，如邮政编码、电话号码等。
- TEXT：适用于存储文章、日记、评论等较长的文本内容。

在选择使用哪种类型时，需要根据实际的业务需求和存储数据的特征来决定，同时考虑到存储效率、查询性能以及存储空间的利用率。

29. CHAR和VARCHAR的区别

CHAR和VARCHAR是两种用于存储字符串数据的数据类型，它们在数据库中各有不同的特点和适用场景：

存储长度：
- CHAR：固定长度的字符串类型。当你为CHAR类型的列指定长度时（例如CHAR(10)），无论实际存储的字符串有多短，都会占用指定长度的存储空间。如果字符串长度小于指定长度，则右侧剩余空间通常会被填充空格以达到预定长度。
- VARCHAR：变长字符串类型。VARCHAR类型的列会根据实际存储内容的长度来分配存储空间，只会占用足够的空间存储实际内容。例如，如果你为VARCHAR(10)类型的列存储了一个长度为5的字符串，那么只会占用5个字符的空间。
存储效率与空间消耗：
- CHAR：因为其定长性质， CHAR类型的列在物理存储上排列整齐，适合高度结构化的数据，如邮政编码、身份证号等固定长度的数据。但如果大多数数据都未达到最大长度，可能会造成存储空间的浪费。
- VARCHAR：在存储变长数据时， VARCHAR类型的列可以节省存储空间，尤其是对于长度变化较大的字符串。然而，由于VARCHAR是变长的，查询时可能需要额外的开销来计算实际数据的位置。
性能：
- CHAR：由于数据长度固定，对于查询和排序操作而言，CHAR类型的列在某些情况下可能有更高的性能优势。
- VARCHAR：在进行查询和排序时，数据库可能需要额外的处理来确定实际存储的字符长度，这在大数据量下可能会影响性能，但对于存储和查询变长数据较为高效。
最大长度：
- 不同数据库系统对CHAR和VARCHAR的最大长度有不同的限制，但总体上VARCHAR可以存储更长的字符串。

综上所述，选择CHAR还是VARCHAR，主要取决于具体应用需求，包括数据的长度变化范围、存储空间利用率、查询性能等因素。对于长度固定的短字符串，CHAR是一个好选择；而对于长度可变且变化范围较大的字符串，VARCHAR更适合。

30. 反射和使用场景

反射（Reflection）在编程中是一个强大的特性，它允许在运行时检查和修改程序本身的行为，包括但不限于获取类、接口、字段和方法的信息，创建和操作对象实例，调用私有方法和修改私有字段等。以下是反射的一些核心特点和使用场景：

类信息获取：
- 在运行时动态获取类的所有属性、方法、构造器、父类、接口等信息，这对于动态生成代码或元编程很有用。
动态类加载与实例化：
- 根据字符串形式的类名在运行时动态加载类并创建其实例，常用于实现插件系统、动态代理或者根据配置文件创建对象等场景。
访问私有成员：
- 反射可以突破封装，访问和修改私有字段，这对于调试、测试以及一些特定的框架内部实现是必要的。
方法调用与参数注入：
- 可以在运行时调用任意对象的任意方法，甚至包括私有方法，这在依赖注入框架、ORM框架以及动态执行用户提供的代码时十分有用。
注解处理：
- 通过反射可以读取类或方法上的注解信息，从而实现注解驱动的框架，例如Spring框架中的依赖注入、事务管理等，都是基于注解并通过反射机制来实现的。
动态代理：
- Java中的动态代理技术（如Java自带的Proxy类或CGLIB库）在创建代理对象时，会利用反射来调用原始对象的方法。
序列化与反序列化：
- 在某些序列化和反序列化框架中，反射用于在对象和字节流之间进行转换，如Java的Externalizable接口或JSON/XML解析器。
单元测试与集成测试：
- 测试框架可以通过反射访问私有方法和字段，进行更全面的测试。
运行时代码生成：
- 可以在运行时根据反射获取的信息生成新的类或方法，实现代码的动态扩展。

总之，反射为程序带来了极大的灵活性，但也可能带来性能开销和安全风险，因此在使用时应当谨慎，并确保只有在必要时才使用反射。

31. Docker常用命令

Docker作为流行的容器化平台，具有丰富的命令集。以下是一些Docker的常用命令分类及其用途：

Docker基础服务管理命令：

启动Docker服务：
```
systemctl start docker
```
停止Docker服务：
```
systemctl stop docker
```
重启Docker服务：
```
systemctl restart docker
```
设置Docker服务开机自启动：
```
systemctl enable docker
```
查看Docker服务运行状态：
```
systemctl status docker
```

Docker镜像相关命令：

列出所有镜像：
```
docker images
```
从仓库拉取镜像：
```
docker pull <image-name[:tag]>
```
搜索仓库中的镜像：
```
docker search <term>
```

删除镜像：

docker rmi <image-id-or-repository[:tag]>

创建新镜像（通常通过Dockerfile构建）：
```
docker build -t <image-name[:tag]> .
```

导入tar文件为新镜像：

docker import [OPTIONS] file|URL|- [REPOSITORY[:TAG]]

Docker容器管理命令：

创建容器但不启动：

docker create [OPTIONS] IMAGE [COMMAND] [ARG...]

运行一个容器：

docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

启动一个或多个已停止的容器：

docker start [OPTIONS] CONTAINER [CONTAINER...]

停止一个运行中的容器：

docker stop [OPTIONS] CONTAINER [CONTAINER...]

重启容器：

docker restart [OPTIONS] CONTAINER [CONTAINER...]

进入正在运行的容器：
```
docker exec -it CONTAINER COMMAND
```

删除容器：

docker rm [OPTIONS] CONTAINER [CONTAINER...]

查看容器日志：
```
docker logs [OPTIONS] CONTAINER
```

其他常用命令：

查看Docker版本信息：
```
docker --version 或 docker version
```
查看Docker资源使用情况：
```
docker system df
```
杀死容器：
```
docker kill CONTAINER
```

提交更改至新镜像：

docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]

更新容器配置：

docker update [OPTIONS] CONTAINER [CONTAINER...]

请注意，以上命令只列举了部分Docker的基本命令，Docker的命令集非常丰富，涵盖了容器、网络、卷、配置等多个方面。在实际使用时，请根据具体需求查阅详细的官方文档或使用docker command --help来获得每个命令的完整帮助信息。

32. Docker部署JAR包的过程

部署Java JAR包到Docker容器的过程一般包括以下步骤：

编写Dockerfile
在项目的根目录下创建一个名为Dockerfile的文件，其中包含构建Docker镜像所需的指令。例如，一个基础的Dockerfile用于部署JAR包可能如下所示：

# 使用官方的Java运行时作为基础镜像
FROM openjdk:8-jdk-alpine

# 设置工作目录
WORKDIR /app

# 将本地的JAR包复制到容器的工作目录中
COPY target/my-app.jar /app/

# 声明环境变量，例如应用的端口
ENV PORT=8080

# 使用ENTRYPOINT指令设置容器启动时执行的命令
ENTRYPOINT ["java", "-jar", "/app/my-app.jar"]

上述Dockerfile假设您的JAR包已经构建完成并且放在项目根目录的target文件夹下，名为my-app.jar。

构建Docker镜像
在终端中切换到包含Dockerfile的目录，然后执行构建命令：
```
docker build -t my-app-image .
```
这将在本地构建一个新的Docker镜像，标签为my-app-image。
运行Docker容器
镜像构建完成后，可以使用以下命令来运行一个新容器：
```
docker run -d -p 8080:8080 --name my-running-app my-app-image
```
-d 参数使容器在后台运行，-p 参数用于端口映射（这里是将容器内部的8080端口映射到主机的8080端口），--name 参数指定容器的名称，最后是刚刚构建的镜像名称。
验证应用运行
应用启动后，可以通过浏览器访问本地的8080端口（如果应用监听的是这个端口）来验证应用是否正常运行。
可选：持久化数据
如果应用需要持久化数据，可以挂载卷（volume）或将数据存储在容器内的特定目录，然后映射到主机的目录。
可选：环境变量配置
通过-e 参数可以设置运行时环境变量，例如设置应用配置项、数据库连接等。

以上就是一个基本的Docker部署Java JAR包的过程，具体步骤可能需要根据应用的实际需求进行调整。

33. Linux远程拷贝命令

在Linux中，远程拷贝命令主要是指scp（Secure Copy）和sftp（Secure File Transfer Protocol）。这两个命令均基于SSH协议，用于在两台Linux主机之间安全地传输文件。

scp（Secure Copy）命令：

# 从本地复制到远程
scp source_file user@remote_host:destination_path

# 示例：将本地的file.txt文件复制到远程服务器的/home/user/目录下
scp file.txt user@remote.example.com:/home/user/

# 从远程复制到本地
scp user@remote_host:source_path destination_file

# 示例：从远程服务器下载/home/user/file.txt到本地当前目录
scp user@remote.example.com:/home/user/file.txt .

# 复制目录（需加上-r参数进行递归复制）
scp -r local_directory user@remote_host:remote_directory

sftp（Secure File Transfer Protocol）命令：

sftp是一个交互式的文件传输程序，可以提供类似FTP的文件传输体验，但基于SSH协议，更安全。

# 启动sftp客户端并连接到远程服务器
sftp user@remote_host

# 连接后，可以使用以下命令进行文件操作
put local_file remote_file        # 上传文件
get remote_file local_file        # 下载文件
ls                                  # 列出远程目录内容
lcd                                 # 改变本地目录
cd remote_directory                # 改变远程目录
mkdir remote_directory             # 创建远程目录
rm remote_file                     # 删除远程文件
exit                                # 退出sftp会话

以上是Linux中进行远程拷贝的常用命令，实际操作时请替换为真实的主机名、用户名、路径和文件名。

34. Linux实时查看日志命令

在Linux系统中，实时查看日志文件的命令通常指的是tail命令搭配 -f（follow）选项。以下是使用tail命令实时查看日志的典型示例：

tail -f /path/to/logfile.log

这条命令会持续显示并实时刷新指定日志文件（如/path/to/logfile.log）的内容，每当日志文件有新增内容时，屏幕会自动显示新加入的日志行。

此外，还有其他一些命令和工具也可以用于实时查看日志，例如：

less命令配合 -F 或 -f 选项（在某些系统中）：
```
less -F /path/to/logfile.log
```
或
```
less +F /path/to/logfile.log
```
这样做的效果和tail -f类似，但less提供了一个可以滚动查看、搜索和退出的界面。
multitail或lnav这类第三方工具，它们可以同时查看多个日志文件并提供了更为丰富的日志查看和分析功能：
```
multitail /path/to/logfile1.log /path/to/logfile2.log
```
或
```
lnav /path/to/logfile.log
```

对于基于Systemd的日志系统（如CentOS 7及更高版本，Ubuntu 15.04及更高版本），可以使用journalctl命令查看实时日志：

journalctl -f

这将实时输出系统日志的变化。如果你想查看特定服务的日志，可以指定服务名称，如：

journalctl -fu apache2.service

35. Linux解压ZIP命令

在Linux系统中，解压ZIP格式的压缩文件，可以使用unzip命令。以下是基本的解压命令格式：

unzip filename.zip

这条命令会将名为filename.zip的压缩文件解压到当前工作目录下。

如果你想将压缩文件解压到指定目录，可以使用 -d 选项指定解压的目标目录：

unzip filename.zip -d /path/to/extract/to/

这条命令会将压缩文件解压到 /path/to/extract/to/ 目录下。

如果ZIP文件包含多个文件和目录，它们都会被解压到指定的目录中。如果目标目录不存在，unzip命令会尝试创建它。

确保你的Linux系统已经安装了unzip工具，如果没有，可以通过包管理器（如apt、yum、dnf等）进行安装。例如，在Debian或Ubuntu系统中安装unzip命令：

sudo apt-get install unzip

鄒彬

关注

21
点赞
踩
11

收藏

觉得还不错? 一键收藏
0
评论
【金三银四】每日一点面试题（面经汇总）百分点java一面1.12

八股拷打的巅峰，纯纯八股。
复制链接

扫一扫