加了一个synchronized锁,程序就崩了

简介: 加了一个synchronized锁,程序就崩了

一 故事背景

一个非常频繁调用方法加了synchronized 导致程序崩溃

二 模拟事故的发生

  1. 创建线程池模拟多用户访问

    ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(10,10,0L,TimeUnit.MICROSECONDS,new ArrayBlockingQueue<>(10));

    for (int i = 0; i <1000; i++) {

    threadPoolExecutor.execute(()->{
        testSync();
    });

    }

    public static synchronized void testSync(){

    try {
        System.out.println("Hi 线程池");
        Thread.sleep(30000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }

    }

会发生以下错误

    Exception in thread "main" java.util.concurrent.RejectedExecutionException: Task com.sunisco.collect.ugqd.web.pages.Test$$Lambda$1/1642360923@6aa8ceb6 rejected from java.util.concurrent.ThreadPoolExecutor@2530c12[Running, pool size = 10, active threads = 10, queued tasks = 10, completed tasks = 0]
            at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
            at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
            at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
            at com.sunisco.collect.ugqd.web.pages.Test.main(Test.java:24)
        
        
这是因为运行的数量大于了队列的数量,修改后继续测试


    ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(10,10,0L,TimeUnit.MICROSECONDS,new ArrayBlockingQueue<>(100));

    for (int i = 0; i <100; i++) {
        threadPoolExecutor.execute(()->{
            testSync();
        });
    }
     
    public static synchronized void  testSync(){
        try {
            System.out.println("Hi 线程池");
            Thread.sleep(30000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
 输出如下
 

image.png

  1. 通过jps查看 所有系统中java进程pid, 找到我们程序的pid 12308

    C:\Users\Administrator>jps
    11088 RemoteMavenServer
    8352 Test
    12308 Test
    10632 Launcher
    9384 Launcher
    11100
    6572 Jps
    9180 Test
    
    
    
    
  2. 通过jstack 12308查看该进程下的线程信息

    C:\Users\Administrator>jstack 12308
    2021-05-13 09:34:53
    Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.141-b15 mixed mode):
    
    "DestroyJavaVM" #21 prio=5 os_prio=0 tid=0x000000001ec4f800 nid=0x27bc waiting on condition [0x0000000000000000]
       java.lang.Thread.State: RUNNABLE
    
    "pool-1-thread-10" #20 prio=5 os_prio=0 tid=0x000000001ec4e000 nid=0x1650 waiting for monitor entry [0x000000001ff8f000]
       java.lang.Thread.State: BLOCKED (on object monitor)
            at com.sunisco.collect.ugqd.web.pages.Test.getg(Test.java:55)
            - waiting to lock <0x000000076b740d80> (a java.lang.Class for com.sunisco.collect.ugqd.web.pages.Test)
            at com.sunisco.collect.ugqd.web.pages.Test.lambda$main$0(Test.java:27)
            at com.sunisco.collect.ugqd.web.pages.Test$$Lambda$1/1642360923.run(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
            at java.lang.Thread.run(Thread.java:748)
    
    "pool-1-thread-9" #19 prio=5 os_prio=0 tid=0x000000001ec4a000 nid=0x2a88 waiting on condition [0x000000001fe8f000]
       java.lang.Thread.State: TIMED_WAITING (sleeping)
            at java.lang.Thread.sleep(Native Method)
            at com.sunisco.collect.ugqd.web.pages.Test.getg(Test.java:56)
            - locked <0x000000076b740d80> (a java.lang.Class for com.sunisco.collect.ugqd.web.pages.Test)
            at com.sunisco.collect.ugqd.web.pages.Test.lambda$main$0(Test.java:27)
            at com.sunisco.collect.ugqd.web.pages.Test$$Lambda$1/1642360923.run(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
            at java.lang.Thread.run(Thread.java:748)
    
    "pool-1-thread-2" #12 prio=5 os_prio=0 tid=0x000000001ea78000 nid=0x1250 waiting for monitor entry [0x000000001f78f000]
       java.lang.Thread.State: BLOCKED (on object monitor)
            at com.sunisco.collect.ugqd.web.pages.Test.getg(Test.java:55)
            - waiting to lock <0x000000076b740d80> (a java.lang.Class for com.sunisco.collect.ugqd.web.pages.Test)
            at com.sunisco.collect.ugqd.web.pages.Test.lambda$main$0(Test.java:27)
            at com.sunisco.collect.ugqd.web.pages.Test$$Lambda$1/1642360923.run(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
            at java.lang.Thread.run(Thread.java:748)

    "pool-1-thread-1" #11 prio=5 os_prio=0 tid=0x000000001ec11800 nid=0xa38 waiting for monitor entry [0x000000001f68f000]
       java.lang.Thread.State: BLOCKED (on object monitor)
            at com.sunisco.collect.ugqd.web.pages.Test.getg(Test.java:55)
            - waiting to lock <0x000000076b740d80> (a java.lang.Class for com.sunisco.collect.ugqd.web.pages.Test)
            at com.sunisco.collect.ugqd.web.pages.Test.lambda$main$0(Test.java:27)
            at com.sunisco.collect.ugqd.web.pages.Test$$Lambda$1/1642360923.run(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
            at java.lang.Thread.run(Thread.java:748)

    "Service Thread" #10 daemon prio=9 os_prio=0 tid=0x000000001e93c000 nid=0x226c runnable [0x0000000000000000]
       java.lang.Thread.State: RUNNABLE

    "C1 CompilerThread2" #9 daemon prio=9 os_prio=2 tid=0x000000001e8c9800 nid=0x21d8 waiting on condition [0x0000000000000000]
       java.lang.Thread.State: RUNNABLE
    "Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x000000001e84b000 nid=0x1c4c runnable [0x000000001f08e000]
       java.lang.Thread.State: RUNNABLE
            at java.net.SocketInputStream.socketRead0(Native Method)
            at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
            at java.net.SocketInputStream.read(SocketInputStream.java:171)
            at java.net.SocketInputStream.read(SocketInputStream.java:141)
            at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
            at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
            at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
            - locked <0x000000076b82f3e0> (a java.io.InputStreamReader)
            at java.io.InputStreamReader.read(InputStreamReader.java:184)
            at java.io.BufferedReader.fill(BufferedReader.java:161)
            at java.io.BufferedReader.readLine(BufferedReader.java:324)
            - locked <0x000000076b82f3e0> (a java.io.InputStreamReader)
            at java.io.BufferedReader.readLine(BufferedReader.java:389)
            at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64)

    "Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x000000001cdf9800 nid=0x35ec waiting on condition [0x0000000000000000]
       java.lang.Thread.State: RUNNABLE

    "Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x000000001cde4800 nid=0x34e8 runnable [0x0000000000000000]
       java.lang.Thread.State: RUNNABLE

    "Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000001cdbf000 nid=0x54c in Object.wait() [0x000000001e12f000]
       java.lang.Thread.State: WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
            - waiting on <0x000000076b188ec8> (a java.lang.ref.ReferenceQueue$Lock)
            at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
            - locked <0x000000076b188ec8> (a java.lang.ref.ReferenceQueue$Lock)
            at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
            at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

    "Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000003687000 nid=0x3318 in Object.wait() [0x000000001e02e000]
       java.lang.Thread.State: WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
            - waiting on <0x000000076b186b68> (a java.lang.ref.Reference$Lock)
            at java.lang.Object.wait(Object.java:502)
            at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
            - locked <0x000000076b186b68> (a java.lang.ref.Reference$Lock)
            at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

    "VM Thread" os_prio=2 tid=0x000000001cd97800 nid=0x2d1c runnable

    "GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00000000035ad000 nid=0x1efc runnable

    "GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00000000035ae800 nid=0xa50 runnable

    "GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00000000035b1000 nid=0x1bac runnable

    "GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00000000035b3000 nid=0x2d50 runnable

    "VM Periodic Task Thread" os_prio=2 tid=0x000000001ea1a800 nid=0x27f4 waiting on condition

    JNI global references: 335

从jstack日志上我们看到许多block状态的线程,生产问题就是因为太多的Block状态的线程,产生的阻塞,最终导致程序的崩溃。

三 结语

锁这种处理并发带来的数据不一致的确有效,但是如果使用不当,对性能会产生极大的影响,所以使用前一定要仔细考虑。

相关文章
|
11月前
多线程-同步代码块中的隐患及解决办法
多线程-同步代码块中的隐患及解决办法
47 0
|
2月前
|
Java 程序员
【面试官】知道synchronized锁升级吗
线程A获取了某个对象锁,但在线程代码的流程中仍需再次获取该对象锁,此时线程A可以继续执行不需要重新再获取该对象锁。既然获取锁的粒度是线程,意味着线程自己是可以获取自己的内部锁的,而如果获取锁的粒度是调用则每次经过同步代码块都需要重新获取锁。此时synchronized重量级锁就回归到了悲观锁的状态,其他获取不到锁的都会进入阻塞状态。来获得锁,CAS操作不需要获得锁、释放锁,减少了像synchronized重量级锁带来的。轻量级锁通过CAS自旋来获得锁,如果自旋10次失败,为了减少CPU的消耗则锁会膨胀为。
|
10月前
|
安全 算法 Java
可重入锁,不可重入锁,死锁的多种情况,以及产生的原因,如何解决,synchronized采用的锁策略(渣女圣经)自适应的底层,锁清除,锁粗化,CAS的部分应用
可重入锁,不可重入锁,死锁的多种情况,以及产生的原因,如何解决,synchronized采用的锁策略(渣女圣经)自适应的底层,锁清除,锁粗化,CAS的部分应用
|
3月前
|
安全 Java
大厂面试题详解:synchronized的偏向锁和自旋锁怎么实现的
字节跳动大厂面试题详解:synchronized的偏向锁和自旋锁怎么实现的
45 0
|
11月前
|
Java 编译器
Java多线程(4)---死锁和Synchronized加锁流程
Java多线程(4)---死锁和Synchronized加锁流程
60 0
|
9月前
|
存储 Java
面试~Synchronized 与 锁升级
面试~Synchronized 与 锁升级
48 0
|
安全 Java 测试技术
【JUC中的 “8锁现象” 】 —— 每天一点小知识
【JUC中的 “8锁现象” 】 —— 每天一点小知识
118 0
【JUC中的 “8锁现象” 】 —— 每天一点小知识
|
安全 Java
Java多线程06—用Lock锁解决线程的安全问题
Java多线程06—用Lock锁解决线程的安全问题
112 0
Java多线程06—用Lock锁解决线程的安全问题
|
设计模式 安全 算法
Java多线程(二)、线程的生命周期、线程的同步、Synchronized的使用方法、同步代码块、同步方法、同步机制中的锁、同步的范围、Lock(锁、不会释放锁的操作、单例设计模式之懒汉式(线程安全)
Java多线程(二)、线程的生命周期、线程的同步、Synchronized的使用方法、同步代码块、同步方法、同步机制中的锁、同步的范围、Lock(锁、不会释放锁的操作、单例设计模式之懒汉式(线程安全)
Java多线程(二)、线程的生命周期、线程的同步、Synchronized的使用方法、同步代码块、同步方法、同步机制中的锁、同步的范围、Lock(锁、不会释放锁的操作、单例设计模式之懒汉式(线程安全)
|
存储 安全 Java
看完你就明白的锁系列之锁的状态
前面两篇文章我介绍了一下 看完你就应该能明白的悲观锁和乐观锁 看完你就明白的锁系列之自旋锁 看完你就会知道,线程如果锁住了某个资源,致使其他线程无法访问的这种锁被称为悲观锁,相反,线程不锁住资源的锁被称为乐观锁,而自旋锁是基于 CAS 机制实现的,CAS又是乐观锁的一种实现,那么对于锁来说,多个线程同步访问某个资源的流程细节是否一样呢?换句话说,在多线程同步访问某个资源时,锁的状态会如何变化呢?本篇文章来探讨一下。
88 0
看完你就明白的锁系列之锁的状态