qq_23204557的博客

动态绑定/运行时绑定内存屏障，有序性，可见性，unsafe

一文的作者有类似的疑惑，按语义，volatile修饰数组时，只是保证其引用地址的可见性，可为什么给数组加了volatile之后，似乎单个数组元素也有了可见性？程序跑很久都不结束，通过debug可以看到线程2一直卡在执行while (b) 那一行。可见虽然非volatilie变量b在线程1中被修改了，但仍对线程2不可见。按照上面的结论，读取一个无关的volatile变量，也会影响此线程的其它变量的可见性。改造的关键无非就是线程中读volatile数组的某元素，它影响了变量b在线程2中的可见性。

为了解决b的可见性问题，使程序正常结束，最简单的方法是用volatile修饰b。程序跑很久都不结束，通过debug可以看到线程2一直卡在执行while (b) 那一行。可见变量b在线程1的synhronized代码块中被修改了，仍对线程2不可见。很多文章说synchronized满足可见性，又没有详细展开，今天我看了一篇。上述方法中，线程1的synchronized代码块保留不保留都不影响结果。，尤其是其中的例2、3、4，对此产生了一些疑惑。所以，到底应该如何理解synchronized的可见性呢？

题目：要求写个Java程序，一个线程专门打印a，另一个线程专门打印b，要求输出为轮流显示a和b，并重复50遍。

例如，线程 T1 执⾏了 1和 3，此时 T2 调⽤ getUniqueInstance () 后发现 uniqueInstance 不为空，因此返回uniqueInstance ，但此时 uniqueInstance 还未被初始化。问题2，双重校验实现单例模式，已经用到了synchronized锁，既然synchronized原子性、可见性、有序性都能保证，为什么还要用volatile?问题1，为什么synchronized未禁止指令重排序，却可以保证有序性？JavaGuide面试突击版。

Read View MVCCMonitor AQS Condition 同步队列 条件队列BlockingQueue

因为设置了线程池的maximumPoolSize为8，我以为提交任务比较多时，会生成8个线程，结果在测试中发现始终都只有4个线程在跑。后来发现是我理解错了（以前背的八卦文忘了好多了-_-）。正确答案应该是当线程数大于corePoolSize数量，并且等待队列已满，但是还没有达到最大线程数maximumPoolSize，则线程池才会创建新的“非核心线程”来执行任务。应该是先存等待队列，等待队列满了才会生成新线程，直到线程数量超过maximumPoolSize则执行拒绝策略。

转自https://www.chenx.tech/priority-blocking-queue/简单来说，方案一：public class Task implements Runnable, Comparable<Task>加ThreadPoolExecutor executor = new ThreadPoolExecutor(..., new PriorityBlockingQueue<>(), ...);executor.execute(task);方案二：

岗位链接电话一面工作内容以及挑战你用的分布式任务调度系统中，是怎么分配计算任务的？分布式CAP理论。为什么不能同时满足C和A？答案：分布式CAP定理，为什么不能同时满足三个特性？之 “二、CAP定理的证明”。问：有哪些分布式的算法？参考答案：Paxos,Raft,Zab从你的理解谈一下RPC，RPC解决了什么技术场景的问题，以及它的原理。RPC与HTTP两者的异同。Kafka对其它MQ的优势。各自能达到什么性能量级？答：单机吞吐量，ActiveMQ与RabbitMQ均为万级，

偏向锁/轻量级锁的加锁和解锁，具体见1AQS中，对状态变量state操作的方法，如tryAcquire、tryRelease等2ConcurrentLinkedDeque和ConcurrentLinkedQueue的入队出队都采用乐观锁，但是size操作需要O(n) 3synchronized在JDK1.6之后的底层优化 ↩︎一些AQS相关的知识 ↩︎蚂蚁面试中视频三面提到了 ↩︎...

状态变量state被volatile修饰，对其操作的方法包括tryAcquire、tryRelease等，都是通过CAS。申请公平锁的线程，会先判断当前队列没有前驱节点（也就是没有线程在等待）时才会CAS修改同步状态变量。而申请非公平锁的线程，则会无视队列，直接CAS抢锁，如果不成功，再进入到队列等待唤醒。1而对于队列中线程的唤醒机制，尚未深入研究，可再研究AQS的非公平锁与同步队列的FIFO冲突吗？，AQS之线程的阻塞和唤醒分析等文章理解ReentrantLock的公平锁和非公平锁 ↩︎

主要参考JavaGuide之JDK1.6之后的底层优化.md无锁 -> 偏向锁 -> 轻量级锁 ->(自旋锁)-> 重量级锁偏向锁的加锁当一个线程访问同步块并获取锁时, 会在锁对象的对象头中的Mark Word和栈帧中的锁记录里存储线程ID轻量级锁使用轻量级锁时，不需要申请互斥量。轻量级锁的加锁和解锁都用到了CAS操作。...

from p90:Executor接口提供了一种将任务提交和任务执行解耦的手段，它基于生产者消费者模式：Executor is based on the producer consumer pattern, where activitiesthat submit tasks are the producers (producing units of work to bedone) and the threads that execute tasks are the consumers (cons

为推荐的一种方法，可防止反射攻击。public class Singleton { // 私有构造函数 private Singleton() { } public static Singleton getInstance() { return SingletonEnum.INSTANCE.getInstance(); } private enum SingletonEnum { INSTANCE;

跳表的实例：jdk中的ConcurrentSkipListMap、ConcurrentSkipListSet，以及Redis，levelDBCopyOnWriteArrayList并发安全。修改时会先lock, 然后 copy完整的数组，在这份复制的数组中进行修改，再把数组的引用指向此新数组。读方法未进行同步控制。所以有线程写数组时，读线程也不会阻塞，只是读到的是旧数组的数据。CopyOnWriteArrayList反映了读写分离的思想。它对比读写锁的优点：读写锁的写是独享的，即读写互斥。而CopyOn

jdk1.8中的ConcurrentHashMap的putVal方法：Node<K,V> f;...else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { //hash指向的索引无Node(键值对)时，使用CAS向其存入Node if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value, null))

Atomic类通过volatile与CAS实现线程安全，它的value字段都被volatile修饰。例1:以AtomicInteger类的getAndIncrement()方法为例，它调用unsafe.getAndAddInt方法，而后者实际上就是CAS+自旋。例2：private AtomicReference<Thread> owner = new AtomicReference<Thread>();void lock(){ owner.compareAnd.

Java SE 6 Performance White Paper中的2.1.2 Lock Coarsening等节描述了jdk1.6对锁一

线程不安全的必要条件： 多线程操作同一共享变量，且其中存在写操作以下代码示范了对变量i的有原子性的方法add()，调用Unsafe, 基于CAS实现public class CASDemo { volatile private int i = 0; static Unsafe unsafe; private static long valueOffset; //i的内存偏移 static{// unsafe = Unsafe.getUnsafe();

import java.util.concurrent.TimeUnit;public class VisibilityDemo { private boolean flag = true; public static void main(String[] args) throws InterruptedException { VisibilityDemo demo = new VisibilityDemo(); new Thread(()->{ int i=0; whi

为什么ThreadPoolExecutor使用的是BlockingQueue？参考不怕难之BlockingQueue及其实现，因为：入队方法比如有：offer(E e)：如果队列没满，立即返回true； 如果队列满了，立即返回false–>不阻塞put(E e)：如果队列满了，一直阻塞，直到队列不满了或者线程被中断–>阻塞JDK文档对put(E e)的描述：Inserts the specified element into this queue, waiting if necess.

old《1.1.2 线程状态》：考研的OS教科书里告诉我们，线程可以有五种状态：开始，就绪，运行，阻塞(等待)，结束。而JDK对线程的状态是这样的：A thread can be in one of the following states:NEWA thread that has not yet started is in this state.RUNNABLEA thread executing in the Java virtual machine is in this state.BL

我的大致总结：HashTable所有的读写类方法，都是synchronized；ConcurrentHashMap(jdk1.8)只有put等写的方法才有synchronized代码块, get没有。Vector所有的读写类方法，都是synchronized；CopyOnWriteArrayList只有写的方法才用到了ReentrantLock, get没有。由此联想到数据库事务里的共享...

wait//释放锁并开始等待, 此线程进入wait队列notify会随机唤醒一个对应monitor的wait list中的线程（此线程仍然需要拿到monitor后才能继续运行）from《实战Java高并发程序设计》p44, shizhansynchronized WaitNotify.java...