java 多线程synchronized同步锁锁住相同用户Id

本文针对Java中synchronized锁无法有效锁定Long类型userId的问题,提出了一种优化方案。通过使用两个HashMap缓存对象引用,解决了锁地址不同的问题,同时避免了内存占用过多的情况。介绍了具体的实现方法和应用场景。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

本文介绍使用java synchronized同步锁来实现对相同userId进行加锁

众所周知synchronized只能锁对象地址,而对于如下加锁是完全没有用的

    public void test(Long userId) {
        synchronized (userId) {//除了-127-128外其他的值都锁不住
//            ...
        }
    }

原因就在于±127之外的都是new除来的Long(见源码Long.valueOf),地址值当然不一样了。

 

既然synchronized需要同一个对象,那我们将同一对象缓存下来不就得了。

    private HashMap<Long, Long> mMap = new HashMap<>();
    public Long getLock(Long userId) {
        if (!mMap.containsKey(userId)) {
            mMap.put(userId, userId);
        }
        return mMap.get(userId);
    }

思路是对的,但:getLock本身就会有并发问题;每个需要锁的接口都得new一个全局的HashMap;当10000个用户调用了100个接口总计要保存1000000条userId在内存里,服务器运行时间越长积累越多。

于是改成了如下方式,代码虽长了一点,但效率几乎没有下降:

/**
 * 由于synchronized只能锁对象的地址,所有像Long为1000的用户id是锁不住的
 * 此类来解决这个问题
 * synchronized (UserLockUtils.getLock("test" + userId)) {}
 * 因为是全局的入参当然是"接口名+userId"最好了
 */
public class UserLockUtils {
    private static HashMap<String, String> mMapId = new HashMap<>(), mMapIdCache = new HashMap<>();
    /**
     * 缓存切换的开始时间,等待{@link #mCacheDeleteTime}时间后将清空切换数据
     */
    private static long mCacheCreatTime;
    /**
     * 最大缓存数(当超出这一数值时,会自动清空),缓存切换等待时间
     */
    private static int mMaxCache = 1000, mCacheDeleteTime = 10000;

    public static synchronized String getLock(String oldId) {
        String returnSt;
        if (mMapId.size() < mMaxCache) {//数据比较少,普通的返回锁
            if (!mMapId.containsKey(oldId)) {
                mMapId.put(oldId, oldId);
            }
            returnSt = mMapId.get(oldId);
        } else {//累加的残留数据太多,切换至缓存
            //缓存开始时间
            long nowMills = System.currentTimeMillis();
            if (mMapIdCache.size() == 0) {
                mCacheCreatTime = nowMills;
            }

            if (!mMapIdCache.containsKey(oldId)) {
                mMapIdCache.put(oldId, mMapId.getOrDefault(oldId, oldId));
            }
            returnSt = mMapIdCache.get(oldId);

            //等待mCacheChangeTime时间后清除原始数据
            if (nowMills - mCacheCreatTime > mCacheDeleteTime) {
                mMapId.clear();
                //原始和缓存对调即可实现切换
                HashMap<String, String> change = mMapId;
                mMapId = mMapIdCache;
                mMapIdCache = change;
            }
        }
        return returnSt;
    }
}

举例:登录接口,我们只需要传“接口名+userId”就可以对登录接口的userId加锁了。

    public void login(Long userId) {
        synchronized (UserLockUtils.getLock("login" + userId)) {
//            ...
        }
    }

尽量不要直接传userId哦,如果所有接口都直接传userId估计就锁死了。

分析一下 "XNIO-2 task-52" #599 prio=5 os_prio=0 tid=0x000055eb63293800 nid=0x25d waiting for monitor entry [0x00007f6263877000] java.lang.Thread.State: BLOCKED (on object monitor) at java.lang.Throwable.fillInStackTrace(Native Method) at java.lang.Throwable.fillInStackTrace(Throwable.java:783) - locked <0x00000000eaac4a38> (a java.lang.reflect.InvocationTargetException) at java.lang.Throwable.<init>(Throwable.java:310) at java.lang.Exception.<init>(Exception.java:102) at java.lang.ReflectiveOperationException.<init>(ReflectiveOperationException.java:89) at java.lang.reflect.InvocationTargetException.<init>(InvocationTargetException.java:72) at sun.reflect.GeneratedMethodAccessor134.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:426) at com.sun.proxy.$Proxy91.selectList(Unknown Source) at org.mybatis.spring.SqlSessionTemplate.selectList(SqlSessionTemplate.java:223) at com.baomidou.mybatisplus.core.override.MybatisMapperMethod.executeForMany(MybatisMapperMethod.java:173) at com.baomidou.mybatisplus.core.override.MybatisMapperMethod.execute(MybatisMapperMethod.java:78) at com.baomidou.mybatisplus.core.override.MybatisMapperProxy$PlainMethodInvoker.invoke(MybatisMapperProxy.java:148) at com.baomidou.mybatisplus.core.override.MybatisMapperProxy.invoke(MybatisMapperProxy.java:89) at com.sun.proxy.$Proxy185.selectList(Unknown Source) at sun.reflect.GeneratedMethodAccessor187.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:344) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
最新发布
03-21
<think>好的,我现在需要帮助用户分析Java中的线程阻塞问题,特别是涉及MyBatis Plus和Spring AOP集成时可能出现的死情况。首先,我得回忆一下相关的知识点,然后结合用户提供的引用内容来梳理可能的原因和解决方案。 用户提到的线程状态是“BLOCKED (on object monitor)”,根据引用[2],这说明线程在等待进入一个同步块或等待获取对象监视器。这时候可能有多个线程在竞争同一个,导致死。接下来,用户提到使用MyBatis Plus和Spring AOP,这两者的集成可能带来什么问题呢? 首先,Spring AOP通常使用动态代理,如果在事务管理或切面中涉及到同步代码块或方法,可能会导致竞争。例如,如果在AOP增强的方法中有同步操作,多个线程调用这些方法时可能会争用同一个。如果MyBatis Plus的操作在这些同步块内,而数据库连接池或ORM框架本身的资源管理不当,可能加剧这种竞争。 然后,考虑MyBatis Plus本身是否可能引发问题。比如,某些方法是否使用了同步机制?或者在使用反射时(如用户提到的“reflectived”)是否没有正确处理?例如,MyBatis Plus的某些方法可能通过反射调用,如果反射过程中持有,而另一个线程也需要同样的,就会导致死。 接下来,用户提到线程名称是“XNIO-2 task”,这可能涉及到XNIO的工作线程池。如果任务处理过程中,这些线程在等待某个资源,而该资源被另一个线程持有,就可能出现阻塞。比如,数据库连接池资源不足时,线程等待连接,而连接被其他长时间运行的事务占用,导致阻塞。这种情况下,可能需要检查连接池配置,如最大连接数是否合理,或者是否有未正确释放连接的情况。 结合引用[3]中的内存溢出问题,虽然用户当前的问题不是内存溢出,但高并发下的资源竞争可能导致类似的问题。比如,如果线程阻塞导致任务堆积,进而消耗大量内存,可能引发溢出。但当前重点还是在线程阻塞和死上。 用户提供的引用[4]虽然涉及前端错误,但提醒我要注意框架本身的潜在问题。例如,某些框架的组件可能存在隐藏的同步机制,或者在使用AOP时产生意外的竞争。 现在需要整理出具体的分析步骤: 1. **线程堆栈分析**:获取所有线程的堆栈信息,查找处于BLOCKED状态的线程,看它们等待的和持有的是否有循环依赖,导致死。比如,线程A持有1,等待2;线程B持有2,等待1。 2. **检查同步代码块**:在MyBatis Plus和Spring AOP相关的代码中,寻找synchronized关键字或显式(如ReentrantLock)。特别注意事务管理中的同步,比如@Transactional注解的方法是否被多个线程频繁调用,并且内部有同步机制。 3. **数据库连接池配置**:检查连接池(如HikariCP)的配置,确认最大连接数是否足够,是否有连接泄漏。连接不足会导致线程等待,表现为BLOCKED状态。 4. **AOP代理的影响**:Spring AOP生成的代理对象可能在调用目标方法时增加额外的处理,如果代理方法和被代理方法中有同步块,可能导致的持有者和预期不同,从而引发死。 5. **反射调用问题**:MyBatis Plus可能通过反射调用某些方法,如果反射过程中涉及到,而反射调用和普通方法调用的竞争不同,可能导致死。需要检查反射调用的代码路径是否有同步问题。 6. **框架内部机制**:检查是否在MyBatis Plus或Spring框架内部使用了特定的机制,如ORM框架的缓存同步、事务同步等,这些可能在并发时产生问题。 可能的解决方案步骤: - **生成线程转储**:使用jstack或jcmd生成线程转储,分析死链。 - **代码审查**:检查涉及MyBatis Plus操作和AOP增强的代码部分,确认同步块的作用域和必要性。 - **调整顺序**:如果多个必须按顺序获取,确保所有线程都按同一顺序获取,避免循环等待。 - **减少同步范围**:尽量减小同步块的范围,或使用更细粒度的。 - **连接池调优**:增加最大连接数,确保连接及时释放。 - **异步处理**:对于耗时操作,考虑异步执行,避免阻塞工作线程。 最后,生成相关问题,帮助用户深入理解问题,比如如何检测死、AOP对事务管理的影响等。</think>### Java线程阻塞与MyBatis Plus/Spring AOP死分析 #### 一、线程阻塞原因分析 1. **`BLOCKED (on object monitor)`状态本质** 线程因等待进入同步代码块或获取对象监视器而阻塞[^2]。当多个线程竞争同一且形成循环等待时,可能导致死。例如: ```java // 线程A持有1,等待2 synchronized(lock1) { synchronized(lock2) { ... } } // 线程B持有2,等待1 synchronized(lock2) { synchronized(lock1) { ... } } ``` 2. **MyBatis Plus与Spring AOP的潜在冲突点** - **动态代理的竞争** Spring AOP通过动态代理实现切面逻辑(如`@Transactional`),若代理方法内部包含同步代码块,可能因代理类和目标类对象不同步导致死。 - **ORM操作与事务同步** MyBatis Plus的数据库操作可能涉及事务管理器对连接的同步控制,若与业务层自定义混合使用,可能引发资源竞争。 --- #### 二、死场景模拟与定位 1. **典型死场景** 假设以下代码使用AOP增强的Service方法: ```java @Service public class UserService { @Transactional public synchronized void updateUser(Long id) { // 同步方法 + 事务代理 // MyBatis Plus操作 userMapper.updateById(...); } } ``` - **风险点**:`synchronized`锁住的是`UserService`实例,而`@Transactional`生成的代理对象可能持有不同,导致事务提交与业务逻辑的顺序冲突。 2. **排查步骤** **(1) 生成线程转储** 使用命令`jstack <pid>`或`jcmd <pid> Thread.print`获取线程堆栈,查找`BLOCKED`状态线程的依赖链[^1]。 **(2) 分析竞争关系** 在堆栈中定位`waiting to lock <0x...>`和`locked <0x...>`的地址,绘制等待图。例如: ``` Thread-X: locked 0x123, waiting for 0x456 Thread-Y: locked 0x456, waiting for 0x123 ``` **(3) 检查框架集成代码** 重点审查以下区域: - MyBatis Plus的`BaseMapper`扩展方法 - Spring AOP切面中涉及资源同步的逻辑 - 事务传播行为(如`REQUIRES_NEW`)与的交互 --- #### 三、解决方案与优化建议 1. **代码层优化** - **避免混合机制** 不在事务代理方法中使用`synchronized`,改用`ReentrantLock`或分布式(如Redis)。 - **缩小同步范围** 将粒度细化到具体资源而非整个方法: ```java private final Object specificLock = new Object(); public void updateUser(Long id) { synchronized(specificLock) { // 仅必要代码段 // 非事务操作 } // 事务操作移至外部 } ``` 2. **框架配置调优** - **调整事务隔离级别** 设置`@Transactional(isolation = Isolation.READ_COMMITTED)`减少竞争。 - **连接池参数优化** 增加数据库连接池的最大连接数(如HikariCP的`maximumPoolSize`),避免连接等待阻塞线程[^3]。 3. **异步化改造** 将耗时操作(如批量写入)移至异步线程池处理: ```java @Async("taskExecutor") public CompletableFuture<Void> asyncUpdate(User user) { userMapper.updateById(user); return CompletableFuture.completedFuture(null); } ``` --- #### 四、工具辅助排查 1. **Arthas诊断工具** 使用`thread -b`命令直接定位死: ```bash $ thread -b Deadlock found between thread-1 and thread-2 ``` 2. **JVisualVM监控** 通过线程时间线视图观察阻塞线程的持续时间和持有者。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值