Java相关

于 2023-09-18 18:14:28 发布
阅读量58 收藏
点赞数
文章标签： java 开发语言
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_65543193/article/details/132968382
版权

Java

JVM

JVM 三色标记与读写屏障

三色标记法
GC垃圾回收器其主要的目的是为了实现内存的回收，在这个过程中主要的两个步骤就是：内存标记，内存回收。
三色标记法简介
三色标记法，主要是为了高效的标记可被回收的内存块。

Java反射获取自定义注解

自定义注解

MethodInfo.java

/**
 * MethodInfo 自定义注解
 *
 * @author lsx
 * @date 2022/6/23 10:41
 * @description TODO
 */
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface MethodInfo {
    String author() default "lsx";

    String date();

    int revision() default 1;

    String comments();
}

类和方法中增加自定义注解

AnnotationDemo.java

package com.aliyun.test.utils;

import java.io.FileNotFoundException;
import java.util.ArrayList;
import java.util.List;

/**
 * 反射解析自定义注解
 *
 * @author lsx
 * @date 2022/6/23 10:43
 * @description TODO
 */
@MethodInfo(author = "Pankaj", comments = "Main method", date = "Nov 17 2012", revision = 66)
public class AnnotationDemo {
    @Override
    @MethodInfo(author = "Pankaj", comments = "Main method", date = "Nov 17 2012", revision = 1)
    public String toString() {
        return super.toString();
    }

    @Deprecated
    @MethodInfo(author = "Json", comments = "deprecated method", date = "Nov 17 2012")
    public static void oldMethod() {
        System.out.println("old method, don't use it.");
    }

    @SuppressWarnings({ "unchecked", "deprecation" })
    @MethodInfo(author = "Pankaj", comments = "Main method", date = "Nov 17 2012", revision = 10)
    public static void genericsTest() throws FileNotFoundException {
        List l = new ArrayList();
        l.add("abc");
        oldMethod();
    }
    
    
    void getName() throws NoSuchMethodException {
        Test test = new Test();
        test.test(this.getClass());
    }
}

通过Java反射机制解析自定义注解

Test.java

package com.aliyun.test.utils;

import java.lang.reflect.Method;

/**
 * @author lsx
 * @date 2022/6/23 10:48
 * @description TODO
 */
public class Test {
    public static void main(String[] args) throws NoSuchMethodException {
        AnnotationDemo annotationDemo = new AnnotationDemo();
        annotationDemo.getName();
    }
    
    void test(Class<?> clazz) throws NoSuchMethodException {
        final MethodInfo annotation = clazz.getAnnotation(MethodInfo.class);
        final String author = annotation.author();
        System.out.println("反射获取的类上面的属性：" + author);
        final Method oldMethod = clazz.getMethod("oldMethod", null);
        final MethodInfo methodInfo = oldMethod.getAnnotation(MethodInfo.class);
        final String author1 = methodInfo.author();
        System.out.println("反射从类方法中获取自定义注解：" + author1);
    }
}

输出结果为：

反射获取的类上面的属性：Pankaj
反射从类方法中获取自定义注解：Json

Java并发

线程的生命周期

生命周期


一个线程从创建，到最终的消亡，需要经历多种不同的状态，而这些不同的线程状态，由始至终也构成了线程生命周期的不同阶 段。线程的生命周期可以总结为下图。

其中，几个重要的状态如下所示。

  • NEW：初始状态，线程被构建，但是还没有调用start()方法。
  • RUNNABLE：可运行状态，可运行状态可以包括：运行中状态和就绪状态。
  • BLOCKED：阻塞状态，处于这个状态的线程需要等待其他线程释放锁或者等待进入synchronized。
  • WAITING：表示等待状态，处于该状态的线程需要等待其他线程对其进行通知或中断等操作，进而进入下一个状态。
  • TIME_WAITING：超时等待状态。可以在一定的时间自行返回。
  • TERMINATED：终止状态，当前线程执行完毕。

    代码示例

    为了更好的理解线程的生命周期，以及生命周期中的各个状态，接下来使用代码示例来输出线程的每个状态信息。

  • WaitingTime   

创建WaitingTime类，在while(true)循环中调用TimeUnit.SECONDS.sleep(long)方法来验证线程的TIMED_WARTING状态，代码如 下所示。

  • WaitingState

创建WaitingState类，此线程会在一个while(true)循环中，获取当前类Class对象的synchronized锁，也就是说，这个类无论创建多 少个实例，synchronized锁都是同一个，并且线程会处于等待状态。接下来，在synchronized中使用当前类的Class对象的wait()方 法，来验证线程的WAITING状态，代码如下所示。

  • BlockedThread

BlockedThread主要是在synchronized代码块中的while(true)循环中调用TimeUnit.SECONDS.sleep(long)方法来验证线程的 BLOCKED状态。当启动两个BlockedThread线程时，首先启动的线程会处于TIMED_WAITING状态，后启动的线程会处于BLOCKED 状态。代码如下所示。

  • ThreadState

启动各个线程，验证各个线程输出的状态，代码如下所示。

运行ThreadState类，如下所示。

可以看到，未输出任何结果信息。可以在命令行输入“jps”命令来查看运行的Java进程。

可以看到ThreadSate进程的进程号为28492，接下来，输入“jstack 28492”来查看ThreadSate进程栈的信息，如下所示。
>jstack 28492

c:\>jstack 28492
2020-02-15 00:27:08
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode):
"DestroyJavaVM" #16 prio=5 os_prio=0 tid=0x000000001ca05000 nid=0x1a4 waiting on condition
[0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"BlockedThread-02" #15 prio=5 os_prio=0 tid=0x000000001ca04800 nid=0x6eb0 waiting for monitor entry
[0x000000001da4f000]
java.lang.Thread.State: BLOCKED (on object monitor)
at io.binghe.concurrent.executor.state.BlockedThread.run(BlockedThread.java:28)
- waiting to lock <0x0000000780a7e4e8> (a java.lang.Class for
io.binghe.concurrent.executor.state.BlockedThread)
at java.lang.Thread.run(Thread.java:748)
"BlockedThread-01" #14 prio=5 os_prio=0 tid=0x000000001ca01800 nid=0x6e28 waiting on condition
[0x000000001d94f000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at java.lang.Thread.sleep(Thread.java:340)
at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
at io.binghe.concurrent.executor.state.WaitingTime.waitSecond(WaitingTime.java:36)
at io.binghe.concurrent.executor.state.BlockedThread.run(BlockedThread.java:28)
- locked <0x0000000780a7e4e8> (a java.lang.Class for
io.binghe.concurrent.executor.state.BlockedThread)
at java.lang.Thread.run(Thread.java:748)
"WaitingStateThread" #13 prio=5 os_prio=0 tid=0x000000001ca06000 nid=0x6fe4 in Object.wait()
[0x000000001d84f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000000780a7b488> (a java.lang.Class for
io.binghe.concurrent.executor.state.WaitingState)
at java.lang.Object.wait(Object.java:502)
at io.binghe.concurrent.executor.state.WaitingState.run(WaitingState.java:29)
- locked <0x0000000780a7b488> (a java.lang.Class for
io.binghe.concurrent.executor.state.WaitingState)
at java.lang.Thread.run(Thread.java:748)
"WaitingTimeThread" #12 prio=5 os_prio=0 tid=0x000000001c9f8800 nid=0x3858 waiting on condition
[0x000000001d74f000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at java.lang.Thread.sleep(Thread.java:340)
at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
at io.binghe.concurrent.executor.state.WaitingTime.waitSecond(WaitingTime.java:36)
at io.binghe.concurrent.executor.state.WaitingTime.run(WaitingTime.java:29)
at java.lang.Thread.run(Thread.java:748)
"Service Thread" #11 daemon prio=9 os_prio=0 tid=0x000000001c935000 nid=0x6864 runnable
[0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C1 CompilerThread3" #10 daemon prio=9 os_prio=2 tid=0x000000001c88c800 nid=0x6a28 waiting on condition
[0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread2" #9 daemon prio=9 os_prio=2 tid=0x000000001c880000 nid=0x6498 waiting on condition
[0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread1" #8 daemon prio=9 os_prio=2 tid=0x000000001c87c000 nid=0x693c waiting on condition
[0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" #7 daemon prio=9 os_prio=2 tid=0x000000001c87b800 nid=0x5d00 waiting on condition
[0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x000000001c862000 nid=0x6034 runnable
[0x000000001d04e000]
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 <0x0000000780b2fd88> (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 <0x0000000780b2fd88> (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=0x000000001c788800 nid=0x6794 waiting on condition
[0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x000000001c7e3800 nid=0x3354 runnable
[0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000001c771000 nid=0x6968 in Object.wait()
[0x000000001cd4f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000000780908ed0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
- locked <0x0000000780908ed0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)
"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x000000001c770800 nid=0x6590 in Object.wait()
[0x000000001cc4f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000000780906bf8> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- locked <0x0000000780906bf8> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
"VM Thread" os_prio=2 tid=0x000000001a979800 nid=0x5c2c runnable
"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00000000033b9000 nid=0x4dc0 runnable
"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00000000033ba800 nid=0x6690 runnable
"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00000000033bc000 nid=0x30b0 runnable
"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00000000033be800 nid=0x6f68 runnable
"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x00000000033c1000 nid=0x6478 runnable
"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x00000000033c2000 nid=0x4fe4 runnable
"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x00000000033c5000 nid=0x584 runnable
"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x00000000033c6800 nid=0x6988 runnable
"VM Periodic Task Thread" os_prio=2 tid=0x000000001c959800 nid=0x645c waiting on condition
JNI global references: 12

由以上输出的信息可以看出：名称为WaitingTimeThread的线程处于TIMED_WAITING状态；名称为WaitingStateThread的线程处于 WAITING状态；名称为BlockedThread-01的线程处于TIMED_WAITING状态；名称为BlockedThread-02的线程处于BLOCKED状 态。

注意：使用jps结合jstack命令可以分析线上生产环境的Java进程的异常信息。

也可以直接点击IDEA下图所示的图表直接打印出线程的堆栈信息。

输出的结果信息与使用“jstack 进程号”命令输出的信息基本一致。

ThreadPoolExecutor的基础变量 ctl 、 runState 和 workerCount

1、一些基础知识

-1<< 29 的计算过程

Java 中基于 32 位补码进行运算

-1的原码为：1000 0000 0000 0000 0000 0000 0000 0001

-1的反码为：1111 1111 1111 1111 1111 1111 1111 1110

-1的补码为：1111 1111 1111 1111 1111 1111 1111 1111

-1的补码左移29位补码：1110 0000 0000 0000 0000 0000 0000 0000

-1的补码左移29位反码：1101 1111 1111 1111 1111 1111 1111 1111

-1的补码左移29位原码：1010 0000 0000 0000 0000 0000 0000 0000

结果为-2的29次幂，即真值为-536870912

Java 线程池的初始化:以 ThreadPoolExecutor 为例

ThreadPoolExecutor 承载了线程池诸多核心逻辑。了解线程池的核心运行逻辑就无法避开这个类。

基础变量 COUNT_BITS、CAPACITY

ThreadPoolExecutor.java

private static final int COUNT_BITS = Integer.SIZE - 3; //32-3=29

private static final int CAPACITY   = (1 << COUNT_BITS) - 1; //(1 << 29) - 1

1 << 29

1原码反码补码：0000 0000 0000 0000 0000 0000 0000 0001

1左移29位原码反码补码：0010 0000 0000 0000 0000 0000 0000 0000

即2的29次幂-1 = 536870911

是所有变量最初始值。它的值为 29
剩余的 CAPACITY、RUNNING、SHUTDOWN、STOP、TIDYING、TERMINATED 都是某个基础数字左移 COUNT_BITS 相关的计算，是固定值

CAPACITY 补码形式为 00011111111111111111111111111111

ThreadPoolExecutor详解及线程池优化

前言
ThreadPoolExecutor在concurrent包下，是我们最常用的类之一。无论是做大数据的，还是写业务开发，对其透彻的理解以及如何发挥更好的性能，成为了我们在更好的coding道路上必不可少的基础。
为什么用线程池？
如果并发的请求数量非常多，但每个线程执行的时间很短，这样就会频繁的创建和销毁线程，如此一来会大大降低系统的效率。这就是线程池的目的了。线程池为线程生命周期的开销和资源不足问题提供了解决方案。通过对多个任务重用线程，线程创建的开销被分摊到了多个任务上。
创建ThreadPoolExecutor
ThreadPoolExecutor总共有四个构造方法，下面选择了一个最全参数的构造方法进行分析。

ThreadPoolExecutor.java

    /**
     * Creates a new {@code ThreadPoolExecutor} with the given initial
     * parameters.
     *
     * @param corePoolSize the number of threads to keep in the pool, even
     *        if they are idle, unless {@code allowCoreThreadTimeOut} is set
     * @param maximumPoolSize the maximum number of threads to allow in the
     *        pool
     * @param keepAliveTime when the number of threads is greater than
     *        the core, this is the maximum time that excess idle threads
     *        will wait for new tasks before terminating.
     * @param unit the time unit for the {@code keepAliveTime} argument
     * @param workQueue the queue to use for holding tasks before they are
     *        executed.  This queue will hold only the {@code Runnable}
     *        tasks submitted by the {@code execute} method.
     * @param threadFactory the factory to use when the executor
     *        creates a new thread
     * @param handler the handler to use when execution is blocked
     *        because the thread bounds and queue capacities are reached
     * @throws IllegalArgumentException if one of the following holds:<br>
     *         {@code corePoolSize < 0}<br>
     *         {@code keepAliveTime < 0}<br>
     *         {@code maximumPoolSize <= 0}<br>
     *         {@code maximumPoolSize < corePoolSize}
     * @throws NullPointerException if {@code workQueue}
     *         or {@code threadFactory} or {@code handler} is null
     */
    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {
        if (corePoolSize < 0 ||
            maximumPoolSize <= 0 ||
            maximumPoolSize < corePoolSize ||
            keepAliveTime < 0)
            throw new IllegalArgumentException();
        if (workQueue == null || threadFactory == null || handler == null)
            throw new NullPointerException();
        this.acc = System.getSecurityManager() == null ?
                null :
                AccessController.getContext();
        this.corePoolSize = corePoolSize;
        this.maximumPoolSize = maximumPoolSize;
        this.workQueue = workQueue;
        this.keepAliveTime = unit.toNanos(keepAliveTime);
        this.threadFactory = threadFactory;
        this.handler = handler;
    }
  • corePoolSize

核心线程数，当有任务在execute()方法提交时，会执行以下判断：

  • 如果运行的线程少于 corePoolSize，则创建新线程来处理任务，即使线程池中的其他线程是空闲的；
  • 如果线程池中的线程数量大于等于 corePoolSize 且小于 maximumPoolSize，则只有当workQueue满时才创建新的线程去处理任务；
  • 如果设置的corePoolSize 和 maximumPoolSize相同，则创建的线程池的大小是固定的，这时如果有新任务提交，若workQueue未满，则将请求放入workQueue中，等待有空闲的线程去从workQueue中取任务并处理；

所以，任务提交时，判断的顺序为 corePoolSize –> workQueue –> maximumPoolSize。

  • maximumPoolSize
    • 最大线程数量；
  • keepAliveTime
    • 线程的存活时间。当线程池里的线程数大于corePoolSize时，如果超过keepAliveTime时长还没有任务可执行，则线程退出。
  • unit
    • 这个用来指定keepAliveTime的单位，比如秒:TimeUnit.SECONDS。
  • workQueue
    • 保存等待执行的任务的阻塞队列，当提交一个新的任务到线程池以后, 线程池会根据当前线程池中正在运行着的线程的数量来决定对该任务的处理方式，主要有以下几种处理方式:
      • 直接切换：这种方式常用的队列是SynchronousQueue，但现在还没有研究过该队列，这里暂时还没法介绍；
      • 使用有界队列：一般使用ArrayBlockingQueue。使用该方式可以将线程池的最大线程数量限制为maximumPoolSize，这样能够降低资源的消耗，但同时这种方式也使得线程池对线程的调度变得更困难，因为线程池和队列的容量都是有限的值，所以要想使线程池处理任务的吞吐率达到一个相对合理的范围，又想使线程调度相对简单，并且还要尽可能的降低线程池对资源的消耗，就需要合理的设置这两个数量。
      • 使用无界队列：一般使用基于链表的阻塞队列LinkedBlockingQueue。如果使用这种方式，那么线程池中能够创建的最大线程数就是corePoolSize，而maximumPoolSize就不会起作用了（后面也会说到）。当线程池中所有的核心线程都是RUNNING状态时，这时一个新的任务提交就会放入等待队列中。
        • 如果要想降低系统资源的消耗（包括CPU的使用率，操作系统资源的消耗，上下文环境切换的开销等）, 可以设置较大的队列容量和较小的线程池容量, 但这样也会降低线程处理任务的吞吐量。
        • 如果提交的任务经常发生阻塞，那么可以考虑通过调用 setMaximumPoolSize() 方法来重新设定线程池的容量。（思路类似于BackPressure动态调节，原理不同）
        • 如果队列的容量设置的较小，通常需要将线程池的容量设置大一点，这样CPU的使用率会相对的高一些。但如果线程池的容量设置的过大，则在提交的任务数量太多的情况下，并发量会增加，那么线程之间的调度就是一个要考虑的问题，因为这样反而有可能降低处理任务的吞吐量。
  • threadFactory
    • 它是ThreadFactory类型的变量，用来创建新线程。默认使用Executors.defaultThreadFactory()来创建线程。使用默认的ThreadFactory来创建线程时，会使新创建的线程具有相同的NORM_PRIORITY优先级并且是非守护线程，同时也设置了线程的名称。
  • handler
    • 它是RejectedExecutionHandler类型的变量，表示线程池的饱和策略。如果阻塞队列满了并且没有空闲的线程，这时如果继续提交任务，就需要采取一种策略处理该任务。
    • 线程池提供了4种策略：
      • AbortPolicy：直接抛出异常，这是默认策略；
      • DiscardPolicy：直接丢弃任务；
      • DiscardOldestPolicy：丢弃阻塞队列中靠最前的任务，并执行当前任务；
      • CallerRunsPolicy：用调用者所在的线程来执行任务；

执行流程

任务被提交到线程池，会先判断当前线程数量是否小于corePoolSize，如果小于则创建线程来执行提交的任务，否则将任务放入workQueue队列，如果workQueue满了，则判断当前线程数量是否小于maxinumPoolSize，如果小于则创建线程执行任务，否则就会调用handler，以表示线程池拒绝接收任务。

运行状态

ThreadPoolExecutor.java

    /**
     * The main pool control state, ctl, is an atomic integer packing
     * two conceptual fields
     *   workerCount, indicating the effective number of threads
     *   runState,    indicating whether running, shutting down etc
     *
     * In order to pack them into one int, we limit workerCount to
     * (2^29)-1 (about 500 million) threads rather than (2^31)-1 (2
     * billion) otherwise representable. If this is ever an issue in
     * the future, the variable can be changed to be an AtomicLong,
     * and the shift/mask constants below adjusted. But until the need
     * arises, this code is a bit faster and simpler using an int.
     *
     * The workerCount is the number of workers that have been
     * permitted to start and not permitted to stop.  The value may be
     * transiently different from the actual number of live threads,
     * for example when a ThreadFactory fails to create a thread when
     * asked, and when exiting threads are still performing
     * bookkeeping before terminating. The user-visible pool size is
     * reported as the current size of the workers set.
     *
     * The runState provides the main lifecycle control, taking on values:
     *
     *   RUNNING:  Accept new tasks and process queued tasks
     *   SHUTDOWN: Don't accept new tasks, but process queued tasks
     *   STOP:     Don't accept new tasks, don't process queued tasks,
     *             and interrupt in-progress tasks
     *   TIDYING:  All tasks have terminated, workerCount is zero,
     *             the thread transitioning to state TIDYING
     *             will run the terminated() hook method
     *   TERMINATED: terminated() has completed
     *
     * The numerical order among these values matters, to allow
     * ordered comparisons. The runState monotonically increases over
     * time, but need not hit each state. The transitions are:
     *
     * RUNNING -> SHUTDOWN
     *    On invocation of shutdown(), perhaps implicitly in finalize()
     * (RUNNING or SHUTDOWN) -> STOP
     *    On invocation of shutdownNow()
     * SHUTDOWN -> TIDYING
     *    When both queue and pool are empty
     * STOP -> TIDYING
     *    When pool is empty
     * TIDYING -> TERMINATED
     *    When the terminated() hook method has completed
     *
     * Threads waiting in awaitTermination() will return when the
     * state reaches TERMINATED.
     *
     * Detecting the transition from SHUTDOWN to TIDYING is less
     * straightforward than you'd like because the queue may become
     * empty after non-empty and vice versa during SHUTDOWN state, but
     * we can only terminate if, after seeing that it is empty, we see
     * that workerCount is 0 (which sometimes entails a recheck -- see
     * below).
     */
    private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
    private static final int COUNT_BITS = Integer.SIZE - 3;
    private static final int CAPACITY   = (1 << COUNT_BITS) - 1;

    // runState is stored in the high-order bits
    private static final int RUNNING    = -1 << COUNT_BITS;
    private static final int SHUTDOWN   =  0 << COUNT_BITS;
    private static final int STOP       =  1 << COUNT_BITS;
    private static final int TIDYING    =  2 << COUNT_BITS;
    private static final int TERMINATED =  3 << COUNT_BITS;
  • RUNNING：能接收新提交的任务，并且也能处理阻塞队列中的任务；
  • SHUTDOWN：关闭状态，不在接收新提交的任务，但缺可以继续处理阻塞队列中已保存的任务。在线程池处于RUNNING状态时，调用shutdown()方法会使线程池进入到该状态。（finalize()方法在执行过程中也会调用shutdown()方法进入该状态）；
  • STOP：不能接收新任务，也不能处理队列中的任务，会中断正在处理任务的线程。在线程池处于RUNNING或SHUTDOWN状态时，调用shutdownNow()方法会使线程池进入到该状态；
  • TIDYING：如果所有的任务都已终止了，workerCount（有效线程数为0），线程池进入该状态后会调用terminated()方法进入TERMINATED状态。

LockSupport详解

前言

LockSupport是concurrent包中一个工具类，不支持构造，提供了一堆static方法，比如park(),unpark()等。
LockSupport中的主要成员及其加载时的初始化：

    // Hotspot implementation via intrinsics API
    private static final sun.misc.Unsafe UNSAFE;
    private static final long parkBlockerOffset;
    private static final long SEED;
    private static final long PROBE;
    private static final long SECONDARY;
    static {
        try {
            UNSAFE = sun.misc.Unsafe.getUnsafe();
            Class<?> tk = Thread.class;
            parkBlockerOffset = UNSAFE.objectFieldOffset
                (tk.getDeclaredField("parkBlocker"));
            SEED = UNSAFE.objectFieldOffset
                (tk.getDeclaredField("threadLocalRandomSeed"));
            PROBE = UNSAFE.objectFieldOffset
                (tk.getDeclaredField("threadLocalRandomProbe"));
            SECONDARY = UNSAFE.objectFieldOffset
                (tk.getDeclaredField("threadLocalRandomSecondarySeed"));
        } catch (Exception ex) { throw new Error(ex); }
    }

不难发现，他们在初始化的时候都是通过Unsafe去获得他们的内存地址，这里也可以理解为C中的指针。

Unsafe

Unsafe类可以参考我之前写的文章：深入理解sun.misc.Unsafe原理

parkBlockerOffset

Thread.java

volatile Object parkBlocker;

提供给setBlocker和getBlocker使用。

LockSupport.java

    private static void setBlocker(Thread t, Object arg) {
        // Even though volatile, hotspot doesn't need a write barrier here.
        UNSAFE.putObject(t, parkBlockerOffset, arg);
    }

由于Unsafe.putObject是无视java访问限制，直接修改目标内存地址的值。即使对象被volatile修饰，也是不需要写屏障的。关于屏障概念，可以参考 CyclicBarrier和CountDownLatch的用法与区别

LockSupport.java

    public static Object getBlocker(Thread t) {
        if (t == null)
            throw new NullPointerException();
        return UNSAFE.getObjectVolatile(t, parkBlockerOffset);
    }

这边的偏移量就算Thread这个类里面变量parkBlocker在内存中的偏移量:

JVM的实现可以自由选择如何实现Java对象的“布局“,也就是在内存里Java对象的各个部分放在哪里,包括对象的实例字段和一些元数据之类。 sun.misc.Unsafe里关于对象字段访问的方法把对象布局抽象出来,它提供了objectFieldOffset()方法用于获取某个字段相对 Java对象的“起始地址”的偏移量,也提供了getInt、getLong、getObject之类的方法可以使用前面获取的偏移量来访问某个Java 对象的某个字段。

为什么要用偏移量来获取对象？干吗不要直接写个get,set方法?

parkBlocker就是在线程处于阻塞的情况下才被赋值。线程都已经被阻塞了,如果不通过这种内存的方法,而是直接调用线程内的方法,线程是不会回应调用的。

SEED, PROBE, SECONDARY

如下图中，看到SEED, PROBE, SECONDARY

都是Thread类中的内存偏移地址,主要用于ThreadLocalRandom类进行随机数生成,它要比Random性能好很多,可以看jdk源码ThreadLocalRandom.java了解详情，这儿就不贴了。

wait和notify/notifyAll

在看park()和unpark()之前，不妨来看下在没有LockSupport之前，是怎么实现让线程等待/唤醒的。

在没有LockSupport之前，线程的挂起和唤醒咱们都是通过Object的wait和notify/notifyAll方法实现。

写一段例子代码，线程A执行一段业务逻辑后调用wait阻塞住自己。主线程调用notify方法唤醒线程A，线程A然后打印自己执行的结果。

public class ThreadWaitNotifyTest {
    public static void main(String[] args) throws Exception {
        final Object obj = new Object();
        Thread thread = new Thread(() -> {
            int sum = 0;
            for (int i = 0; i < 10; i++) {
                sum += 1;
            }
            try {
                obj.wait();
            } catch (Exception e) {
                e.printStackTrace();
            }
            System.out.println(sum);
        });
        thread.start();
        //睡眠一分钟，保证线程A已经计算完成，阻塞在wait方法
        Thread.sleep(1000);
        obj.notify();
    }
}

根据上述执行发现抛了两个，上面的wait方法线程等待正常IllegalMonitorStateException异常，notify方法也抛出一个IllegalMonitorStateException异常。

原因很简单，wait和notify/notifyAll方法只能在同步代码块里用(这个有的面试官也会考察)。所以将代码修改为如下就可正常运行了：

public class ThreadWaitNotifyTest {
    public static void main(String[] args) throws Exception {
        final Object obj = new Object();
        Thread thread = new Thread(() -> {
            int sum = 0;
            for (int i = 0; i < 10; i++) {
                sum += 1;
            }
            try {
                synchronized (obj){
                    obj.wait();
                }
            } catch (Exception e) {
                e.printStackTrace();
            }
            System.out.println(sum);
        });
        thread.start();
        //睡眠一分钟，保证线程A已经计算完成，阻塞在wait方法
        Thread.sleep(1000);
        synchronized (obj){
            obj.notify();
        }
    }
}

这里发现wait和notify并未抛出其他异常。

那如果咱们换成LockSupport呢？简单得很，看代码：

public class ThreadLockSupport {
    public static void main(String[] args) throws Exception {
        Thread thread = new Thread(() -> {
            int sum = 0;
            for (int i = 0; i < 10; i++) {
                sum += 1;
            }
            try {
                LockSupport.park();
            } catch (Exception e) {
                e.printStackTrace();
            }
            System.out.println(sum);
        });
        thread.start();
        //睡眠一分钟，保证线程A已经计算完成，阻塞在wait方法
        Thread.sleep(1000);
        LockSupport.unpark(thread);
    }
}

结果均正常输出，没有抛出任何异常。

LockSupport灵活性

如果只是LockSupport在使用起来比Object的wait/notify简单，那还真没必要专门讲解下LockSupport。最主要的是灵活性。

上边的例子代码中，主线程调用了Thread.sleep(1000)方法来等待线程A计算完成进入wait状态。如果去掉Thread.sleep()调用：

public class ThreadWaitNotifyTest {
    public static void main(String[] args) throws Exception {
        final Object obj = new Object();
        Thread thread = new Thread(() -> {
            int sum = 0;
            for (int i = 0; i < 10; i++) {
                sum += 1;
            }
            try {
                synchronized (obj){
                    obj.wait();
                }
            } catch (Exception e) {
                e.printStackTrace();
            }
            System.out.println(sum);
        });
        thread.start();
        //睡眠一分钟，保证线程A已经计算完成，阻塞在wait方法
        //Thread.sleep(1000);
        synchronized (obj){
            obj.notify();
        }
    }
}

多次执行后，我们会发现：有的时候能够正常打印结果并退出程序，但有的时候线程无法打印结果阻塞住了。原因就在于主线程调用完notify后，线程A才进入wait方法，导致线程A一直阻塞住。由于线程A不是后台线程，所以整个程序无法退出。

那如果换做LockSupport呢？LockSupport就支持主线程先调用unpark后，线程A再调用park而不被阻塞吗？是的，没错。代码如下：

public class ThreadLockSupport {
    public static void main(String[] args) throws Exception {
        Thread thread = new Thread(() -> {
            int sum = 0;
            for (int i = 0; i < 10; i++) {
                sum += 1;
            }
            try {
                LockSupport.park();
            } catch (Exception e) {
                e.printStackTrace();
            }
            System.out.println(sum);
        });
        thread.start();
        //睡眠一分钟，保证线程A已经计算完成，阻塞在wait方法
        //Thread.sleep(1000);
        LockSupport.unpark(thread);
    }
}

不管你执行多少次，这段代码都能正常打印结果并退出。这就是LockSupport最大的灵活所在。

小结一下，LockSupport比Object的wait/notify有两大优势：
  • LockSupport不需要再同步代码块里。所以线程间也不需要维护一个共享的同步对象，实现了线程间的解耦。
  • unpark函数可以先于park调用，所以不需要的安心线程间的执行的先后顺序。

LockSupport原理

看源码，park和unpark都是直接调用了Unsafe的方法：深入理解sun.misc.Unsafe原理

LockSupport.java

    /**
     * Disables the current thread for thread scheduling purposes unless the
     * permit is available.
     *
     * <p>If the permit is available then it is consumed and the call returns
     * immediately; otherwise
     * the current thread becomes disabled for thread scheduling
     * purposes and lies dormant until one of three things happens:
     *
     * <ul>
     * <li>Some other thread invokes {@link #unpark unpark} with the
     * current thread as the target; or
     *
     * <li>Some other thread {@linkplain Thread#interrupt interrupts}
     * the current thread; or
     *
     * <li>The call spuriously (that is, for no reason) returns.
     * </ul>
     *
     * <p>This method does <em>not</em> report which of these caused the
     * method to return. Callers should re-check the conditions which caused
     * the thread to park in the first place. Callers may also determine,
     * for example, the interrupt status of the thread upon return.
     *
     * @param blocker the synchronization object responsible for this
     *        thread parking
     * @since 1.6
     */
    public static void park(Object blocker) {
        Thread t = Thread.currentThread();
        setBlocker(t, blocker);
        UNSAFE.park(false, 0L);
        setBlocker(t, null);
    }

LockSupport.java

    /**
     * Makes available the permit for the given thread, if it
     * was not already available.  If the thread was blocked on
     * {@code park} then it will unblock.  Otherwise, its next call
     * to {@code park} is guaranteed not to block. This operation
     * is not guaranteed to have any effect at all if the given
     * thread has not been started.
     *
     * @param thread the thread to unpark, or {@code null}, in which case
     *        this operation has no effect
     */
    public static void unpark(Thread thread) {
        if (thread != null)
            UNSAFE.unpark(thread);
    }

LockSupport应用广泛

Future的get方法

LockSupport在Java的工具类用应用很广泛，咱们这里找几个例子感受感受。以Java里最常用的类ThreadPoolExecutor（线程池可参考ThreadPoolExecutor详解及线程池优化）。先看如下代码：

public class ThreadPoolExecutorTest {
    public static void main(String[] args) throws Exception{
        BlockingQueue<Runnable> blockingQueue = new ArrayBlockingQueue<>(1000);
        ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor(5,5,1000, TimeUnit.SECONDS, blockingQueue);
        Future<String> future = poolExecutor.submit(()->{
           TimeUnit.SECONDS.sleep(5);
           return "hello";
        });
        final String result = future.get();
        poolExecutor.shutdown();
        System.out.println(result);
    }
}

代码中我们向线程池中扔了一个任务，然后调用Future的get方法，同步阻塞等待线程池的执行结果。

这里就要问了：get方法是如何阻塞住当前线程？线程池执行完任务后又是如何唤醒线程的呢？

咱们跟着源码一步步分析，先看线程池的submit方法的实现：

AbstractExecutorService.java

    public <T> Future<T> submit(Callable<T> task) {
        if (task == null) throw new NullPointerException();
        RunnableFuture<T> ftask = newTaskFor(task);
        execute(ftask);
        return ftask;
    }

在submit方法里，线程池将我们提交的基于Callable实现的任务，封装为基于RunnableFuture实现的任务，然后将任务提交到线程池执行，并向当前线程返回RunnableFutrue。

进入newTaskFor方法，就一句话：return new FutureTask(callable);

所以，咱们主线程调用future的get方法就是FutureTask的get方法，线程池执行的任务对象也是FutureTask的实例。

接下来看看FutureTask的get方法的实现：

FutureTask.java

    /**
     * @throws CancellationException {@inheritDoc}
     */
    public V get() throws InterruptedException, ExecutionException {
        int s = state;
        if (s <= COMPLETING)
            s = awaitDone(false, 0L);
        return report(s);
    }

比较简单，就是判断下当前任务是否执行完毕，如果执行完毕直接返回任务结果，否则进入awaitDone方法阻塞等待。

FutureTask.java

    /**
     * Awaits completion or aborts on interrupt or timeout.
     *
     * @param timed true if use timed waits
     * @param nanos time to wait, if timed
     * @return state upon completion
     */
    private int awaitDone(boolean timed, long nanos)
        throws InterruptedException {
        final long deadline = timed ? System.nanoTime() + nanos : 0L;
        WaitNode q = null;
        boolean queued = false;
        for (;;) {
            if (Thread.interrupted()) {
                removeWaiter(q);
                throw new InterruptedException();
            }

            int s = state;
            if (s > COMPLETING) {
                if (q != null)
                    q.thread = null;
                return s;
            }
            else if (s == COMPLETING) // cannot time out yet
                Thread.yield();
            else if (q == null)
                q = new WaitNode();
            else if (!queued)
                queued = UNSAFE.compareAndSwapObject(this, waitersOffset,
                                                     q.next = waiters, q);
            else if (timed) {
                nanos = deadline - System.nanoTime();
                if (nanos <= 0L) {
                    removeWaiter(q);
                    return state;
                }
                LockSupport.parkNanos(this, nanos);
            }
            else
                LockSupport.park(this);
        }
    }

awaitDone方法里，首先会用到之前说的CAS操作（参考深入理解sun.misc.Unsafe原理），将线程封装为WaitNode，保持下来，以供后续唤醒线程时用。再就是调用了LockSupport的park/parkNanos组塞住当前线程。

上边已经说完了阻塞等待任务结果的逻辑，接下来再看看线程池执行完任务，唤醒等待线程的逻辑实现。

前边说了，咱们提交的基于Callable实现的任务，已经被封装为FutureTask任务提交给了线程池执行，任务的执行就是FutureTask的run方法执行。如下是FutureTask的run方法：

FutureTask.java

public void run() {
        if (state != NEW ||
            !UNSAFE.compareAndSwapObject(this, runnerOffset,
                                         null, Thread.currentThread()))
            return;
        try {
            Callable<V> c = callable;
            if (c != null && state == NEW) {
                V result;
                boolean ran;
                try {
                    result = c.call();
                    ran = true;
                } catch (Throwable ex) {
                    result = null;
                    ran = false;
                    setException(ex);
                }
                if (ran)
                    set(result);
            }
        } finally {
            // runner must be non-null until state is settled to
            // prevent concurrent calls to run()
            runner = null;
            // state must be re-read after nulling runner to prevent
            // leaked interrupts
            int s = state;
            if (s >= INTERRUPTING)
                handlePossibleCancellationInterrupt(s);
        }
    }

c.call()就是执行我们提交的任务，任务执行完后调用了set方法，进入set方法发现set方法调用了finishCompletion方法，想必唤醒线程的工作就在这里边了，看看代码实现吧：

FutureTask.java

protected void set(V v) {
        if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) {
            outcome = v;
            UNSAFE.putOrderedInt(this, stateOffset, NORMAL); // final state
            finishCompletion();
        }
    }

这边通过CAS操作将所有等待的线程拿出来，感觉越来越接近了，再看下最后完成方法finishCompletion：
FutureTask.java

    private void finishCompletion() {
        // assert state > COMPLETING;
        for (WaitNode q; (q = waiters) != null;) {
            if (UNSAFE.compareAndSwapObject(this, waitersOffset, q, null)) {
                for (;;) {
                    Thread t = q.thread;
                    if (t != null) {
                        q.thread = null;
                        LockSupport.unpark(t);
                    }
                    WaitNode next = q.next;
                    if (next == null)
                        break;
                    q.next = null; // unlink to help gc
                    q = next;
                }
                break;
            }
        }

        done();

        callable = null;        // to reduce footprint
    }

果然，这边使用LockSupport的unpark唤醒每个线程。

ps. 这边对无用变量的回收细节也是十分惊人，可以看上方的代码注释。

阻塞队列中的应用

在使用线程池的过程中，不知道你有没有这么一个疑问：线程池里没有任务时，线程池里的线程在干嘛呢？

看过我的这篇文章ThreadPoolExecutor详解及线程池优化的一定知道，线程会调用队列的take方法阻塞等待新任务。那队列的take方法是不是也跟Future的get方法实现一样呢？咱们来看看源码实现。

ArrayBlockingQueue.java

    public E take() throws InterruptedException {
        final ReentrantLock lock = this.lock;
        lock.lockInterruptibly();
        try {
            while (count == 0)
                notEmpty.await();
            return dequeue();
        } finally {
            lock.unlock();
        }
    }

与想象的有点出入，他是使用了Lock的Condition的await方法实现线程阻塞。但当我们继续追下去进入await方法，发现是通过AQS的await方法实现的，还是使用了LockSupport：

AbstractQueuedSynchronizer.java

        public final void await() throws InterruptedException {
            if (Thread.interrupted())
                throw new InterruptedException();
            Node node = addConditionWaiter();
            int savedState = fullyRelease(node);
            int interruptMode = 0;
            while (!isOnSyncQueue(node)) {
                LockSupport.park(this);
                if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                    break;
            }
            if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
                interruptMode = REINTERRUPT;
            if (node.nextWaiter != null) // clean up if cancelled
                unlinkCancelledWaiters();
            if (interruptMode != 0)
                reportInterruptAfterWait(interruptMode);
        }

小结

多次调用unpark方法和调用一次unpark方法效果一样，因为都是直接将_counter赋值为1，而不是加1。简单说就是：线程A连续调用两次LockSupport.unpark(B)方法唤醒线程B，然后线程B调用两次LockSupport.park()方法， 线程B依旧会被阻塞。因为两次unpark调用效果跟一次调用一样，只能让线程B的第一次调用park方法不被阻塞，第二次调用依旧会阻塞。

一念~天涯
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值