一起科技（类加载器/volatile/线程池初始化）_指定线程池的类加载器-优快云博客

本文链接：https://blog.youkuaiyun.com/maydayAsh/article/details/91511258

1.jdk提供的默认类加载器：

bootstrap classloader（它用来加载Java的核心库(JAVA_HOME/jre/lib/rt.jar 或 sun.boot.class.path 路径下的内容）），extensionclassloader（用来加载Java的扩展库(JAVA_HOME/jre/lib/ext/*.jar或 java.ext.dirs路径下的内容) ），application classloader（Java应用的类都是由它来完成加载的）。
作用：将class文件字节码内容加载到内存中，并将这些静态数据转换成方法区中的运行时数据结构，在堆中生成一个代表这个类的java.lang.Class对象，作为方法区类数据的访问入口。
双亲委派模型工作过程：如果一个类加载器收到类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器完成。每个类加载器都是如此，只有当父加载器在自己的搜索范围内找不到指定的类时（即ClassNotFoundException），子加载器才会尝试自己去加载。
为什么需要双亲委派模型？
试想一个场景：
| 黑客自定义一个java.lang.String类，该String类具有系统的String类一样的功能，只是在某个函数稍作修改。比如equals函数，这个函数经常使用，如果在这这个函数中，黑客加入一些“病毒代码”。并且通过自定义类加载器加入到JVM中。此时，如果没有双亲委派模型，那么JVM就可能误以为黑客自定义的java.lang.String类是系统的String类，导致“病毒代码”被执行。 |
而有了双亲委派模型，黑客自定义的java.lang.String类永远都不会被加载进内存。因为首先是最顶端的类加载器加载系统的java.lang.String类，最终自定义的类加载器无法加载java.lang.String类。

或许你会想，我在自定义的类加载器里面强制加载自定义的java.lang.String类，不去通过调用父加载器不就好了吗?确实，这样是可行。但是，在JVM中，判断一个对象是否是某个类型时，如果该对象的实际类型与待比较的类型的类加载器不同，那么会返回false。

2.volatile关键字：

保证内存可见性（但不保证操作的原子性）。
防止指令重排（在指令序列中插入内存屏障）。
-下面是基于保守策略的JMM内存屏障插入策略：
在每个volatile写操作的前面插入一个StoreStore屏障。
在每个volatile写操作的后面插入一个StoreLoad屏障。
在每个volatile读操作的前面插入一个LoadLoad屏障。
在每个volatile读操作的后面插入一个LoadStore屏障。

3.volatile和synchronized的区别：

volatile不会进行加锁操作，volatile变量是一种比synchronized关键字更轻量级的同步机制。
volatile不如synchronized安全
volatile无法同时保证内存可见性和原则性
当且仅当满足以下所有条件时，才应该使用volatile变量：
①对变量的写入操作不依赖变量的当前值，或者你能确保只有单个线程更新变量的值。
②该变量没有包含在具有其他变量的不变式中。

4.线程池初始化参数：

corePoolSize：线程池的大小
maximumPoolSize：线程池中创建的最大线程数
keepAliveTime：空闲的线程多久时间后被销毁
workQueue：阻塞队列
handler:线程拒绝策略，当创建的线程超出maximumPoolSize，且缓冲队列已满时，新任务会拒绝，有以下取值：
　　ThreadPoolExecutor.AbortPolicy:丢弃任务并抛RejectedExecutionException异常。
　　ThreadPoolExecutor.DiscardPolicy：也是丢弃任务，但是不抛出异常。
　　ThreadPoolExecutor.DiscardOldestPolicy：丢弃队列最前面的任务，然后重新尝试执行任务（重复此过程）
　　ThreadPoolExecutor.CallerRunsPolicy：由调用线程处理该任务

5.ReentrantLock和synchronized使用分析
ReentrantLock是Lock的实现类，是一个互斥的同步器，在多线程高竞争条件下，ReentrantLock比synchronized有更加优异的性能表现。
1 用法比较