Spring（三）

1. Spring单例Bean是不是线程安全的?

Spring单例Bean默认并不是线程安全的。由于多个线程可能访问同一份Bean实例，当Bean的内部包含了可变状态（mutable state）即有可修改的成员变量时，就可能出现线程安全问题。Spring容器不会自动处理这类问题，所以开发者需要自己确保Bean的线程安全性。

例如，你可以通过以下方式解决线程安全问题：

1. 使用@Scope("prototype")使Bean成为多例，每个请求创建新的实例；
2. 对于包含可变状态的Bean，可以在方法级别使用synchronized关键字进行同步控制；
3. 使用Lock接口（如ReentrantLock）提供更细粒度的锁控制；
4. 将可变成员变量放入ThreadLocal中，确保每个线程有自己的独立副本。

举例

Spring单例Bean不是线程安全的原因在于，当多个线程并发访问并修改同一个Bean实例的状态时，可能会导致数据不一致或其他未预期的行为。具体示例可以是这样的：

假设有一个Spring单例Bean，它有一个可变的成员变量：

@Component
public class SingletonBean {private int count = 0;public void increment() {this.count++;}public int getCount() {return this.count;}
}

现在有两个线程A和B并发调用increment()方法，由于没有进行任何同步控制，可能会出现以下情况：

1. 线程A读取count的值为0。
2. 线程B也读取count的值为0。
3. 线程A将count加1，变为1，然后写回。
4. 线程B也将count加1，但由于它之前读到的是0，因此写回的值也是1。

在这种情况下，尽管两个线程都调用了increment()，但最终count的值却只有1，而不是预期的2。这就是线程不安全的表现。

2. ThreadLocal如何帮助解决线程安全问题？

ThreadLocal 是 Java 中的一个类，用于在多线程环境中为每个线程提供独立的变量副本。通过使用 ThreadLocal，可以在一定程度上解决线程安全问题，因为它确保了每个线程都有自己的变量实例，而不会与其他线程共享同一实例。以下是使用 ThreadLocal 的基本步骤：

（1）创建一个继承自 ThreadLocal<T> 的子类，或者直接声明 ThreadLocal 变量来持有特定类型的对象。

ThreadLocal<Integer> threadLocalCount = new ThreadLocal<>();

（2）在需要的地方初始化变量副本。通常是在每次新线程开始执行时（如 Runnable.run() 方法内）。

threadLocalCount.set(0);

（3）当前线程使用这个变量副本时，不需要担心其他线程会修改它的状态。

public void increment() {int currentCount = threadLocalCount.get();threadLocalCount.set(currentCount + 1);
}

（4）不再需要使用变量时，应该清除 ThreadLocal 值以避免内存泄漏。

threadLocalCount.remove();

注意，虽然 ThreadLocal 可以处理与实例状态相关的线程安全问题，但它并不适用于所有场景。例如，如果多个线程需要协调它们的操作，例如同步某个资源，仍然需要使用锁或者其他同步机制。

3. ThreadLocal 如何与 Spring 以及其他框架集成使用？

在 Spring 中使用 ThreadLocal 主要是为了在线程中存储一些特定的数据，这些数据是针对当前线程的局部上下文。下面是一个简单的例子，说明如何在 Spring 中集成并使用 ThreadLocal：

（1）首先，创建一个 ThreadLocal 变量，用于存储你需要在线程间隔离的数据。

public class RequestContext {public static final ThreadLocal<RequestInfo> context = new ThreadLocal<>();// 其他方法和属性...
}

（2）然后，在服务入口处，如过滤器或拦截器中，设置 ThreadLocal 的值。这通常是请求开始时进行的。

@Component
public class RequestFilter implements Filter {@Overridepublic void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {// 获取请求相关的信息，并存入ThreadLocalRequestInfo requestInfo = new RequestInfo(...); // 根据实际情况填充RequestContext.context.set(requestInfo);try {chain.doFilter(request, response);} finally {// 请求结束后清理ThreadLocal，防止内存泄漏RequestContext.context.remove();}}// 其他方法...
}

（3）接下来，你的业务逻辑代码可以通过静态访问 RequestContext.context 来获取当前线程中的请求上下文信息。

@Service
public class MyService {public void processRequest() {RequestInfo requestInfo = RequestContext.context.get();// 使用requestInfo做进一步的业务处理...}// 其他方法...
}

4. Lock接口相比synchronized有何优势？

Java中的Lock接口（位于java.util.concurrent.locks包下）提供了比synchronized关键字更细粒度的锁控制，其主要优势包括：

• 显式锁定：使用synchronized，锁的获取和释放是隐式的。而Lock需要程序员显式地调用lock()和unlock()方法，这种显式控制使代码可读性和灵活性更高，也便于编写复杂的同步代码。

• 可中断等待：Lock的lockInterruptibly()方法允许正在等待获取锁的线程响应中断，而synchronized锁无法做到这一点。当线程被中断时，会抛出InterruptedException。

• 超时等待：tryLock(long time, TimeUnit unit)允许尝试获取锁，如果在指定时间内未能获取到锁，则返回false。与此相反，使用synchronized时，线程会在获取锁的过程中一直阻塞，直到获得锁或者被中断。

• 非公平锁：ReentrantLock（Lock的一个实现）默认是非公平锁，这意味着线程获取锁的机会不保证公平。这可能导致某些线程长时间等待，但synchronized天生是公平的（在JVM层面），所有线程按到达顺序获得锁。

• 更丰富的同步结构：Lock接口支持更高级的并发构建块，例如Condition，它可以创建多个条件变量，允许多组线程独立等待不同的条件，提供更大的灵活性。

5. 当应该优先选择`synchronized`而不是`Lock`时，有哪些情况？

在某些情况下，使用synchronized关键字可能更适合，以下是几个考虑因素：

• 简单性：对于简单的同步场景，如保护单个方法的访问，使用synchronized更简洁。不需要额外的代码来管理锁，降低了出错的可能性。

• 自动解锁：由于synchronized块/方法在异常发生时会自动释放锁，因此在处理异常时无需额外的清理代码。

• 内置特性：synchronized与Java虚拟机紧密集成，提供了内存可见性和原子性保证，这是Lock实现所依赖的基础。

• 性能：虽然在过去，Lock通常比synchronized更快，但在现代Java版本中，两者的性能差异已经很小，甚至在某些情况下synchronized更优。

• 兼容性：有时，现有的类库使用了synchronized，为了保持一致性或利用已有的同步机制，可能会选择继续使用它。