JAVA多线程/并发——问题与答案（2）

线程安全

1，什么是线程安全？

线程安全：多个线程同时访问公共资源数据，运行同一段代码，并且每次执行的结果都与预期结果一致，既为线程安全的。如果执行的结果存在不确定性，既为线程不安全的。

2，servlet是线程安全吗?

servlet不是线程安全的，因为每个servlet在Tomcat是单例的，当多个HTTP请求同时请求同一个servlet时，多个请求对应的线程将并发调用Servlet的service()方法，此时，如果在Servlet中定义了实例变量或静态变量，那么可能会发生线程安全问题。

详情参考：java基础篇（5）——Servlet详解

3，同步有几种实现方法？

    1，同步方法（synchronized关键字修饰的方法）；

    2，同步代码块（synchronized关键字修饰的语句块）；

    3，使用ReentrantLock可重入锁实现线程同步；

    4，线程排队执行

     总结就是加锁和队列

5，volatile有什么用？能否用一句话说明下volatile的应用场景？

     volatile的作用有两点，内存可见性和防止指令重排序。

    内存可见性：根据JMM模型，每个线程内部的工作内存中，保存有公共变量的副本，而volatile的作用就是使工作内存中的变量即时刷新到主内存中。

    防止指令重排序：根据happens-before原则，对volatile变量的写操作 happens-before于对该变量的读。

    volatile的使用场景：

            1，状态标志；2，独立观察；3，开销较低的“读－写锁”策略

6，请说明下java的内存模型及其工作流程。

Java的内存模型JMM（Java Memory Model）JMM主要是为了规定了线程和内存之间的一些关系。根据JMM的设计，系统存在一个主内存(Main Memory)，Java中所有实例变量都储存在主存中，对于所有线程都是共享的。每条线程都有自己的工作内存(Working Memory)，工作内存由缓存和堆栈两部分组成，缓存中保存的是主存中变量的副本，缓存可能并不总和主存同步，也就是缓存中变量的修改可能没有立刻写到主存中；堆栈中保存的是线程的局部变量，线程之间无法相互直接访问堆栈中的变量。 

从上图来看，线程A与线程B之间如要通信的话，必须要经历下面2个步骤：

1. 首先，线程A把本地内存A中更新过的共享变量刷新到主内存中去。
2. 然后，线程B到主内存中去读取线程A之前已更新过的共享变量。

7，为什么代码会重排序？

重排序分编译器重排序和处理器重排序，代码在编译时编译器会对代码进行优化重排序。处理器在执行指令时，根据指令并行技术，如果两条指令不存在依赖性，处理器可以改变语句对应指令的执行顺序；而且由于处理器使用缓存读写，这使得加载和存储操作看上去可能是在乱序执行。

在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序。重排序分三种类型：

1. 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
2. 指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
3. 内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

从java源代码到最终实际执行的指令序列，会分别经历下面三种重排序：

上述的1属于编译器重排序，2和3属于处理器重排序。这些重排序都可能会导致多线程程序出现内存可见性问题。对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM的处理器重排序规则会要求java编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers，intel称之为memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）。

并发容器和框架

1，如何让一段程序并发的执行，并最终汇总结果？

使用CyclicBarrier 在多个关口处将多个线程执行结果汇总 ；CountDownLatch 在各线程执行完毕后向总线程汇报结果。

2，如何合理的配置java线程池？如CPU密集型的任务或IO密集型的任务，基本线程池应该配置多大？

CPU密集型任务可以少配置线程数，大概和机器的cpu核数相当，可以使得每个线程都在执行任务；IO密集型时，大部分线程都阻塞，故需要多配置线程数，2*cpu核数

3，用有界队列好还是无界队列好？任务非常多的时候，使用什么阻塞队列能获取最好的吞吐量？

有界队列和无界队列的配置需区分业务场景，一般情况下配置有界队列，在一些可能会有爆发性增长的情况下使用无界队列。
任务非常多时，使用非阻塞队列使用CAS操作替代锁可以获得好的吞吐量。

4，如何使用阻塞队列实现一个生产者和消费者模型？请写代码。TODO

5，多读少写的场景应该使用哪个并发容器，为什么使用它？比如你做了一个搜索引擎，搜索引擎每次搜索前需要判断搜索关键词是否在黑名单里，黑名单每天更新一次。
 答：1）CopyOnWriteArrayList这个容器适用于多读少写…
        2）读写并不是在同一个对象上。在写时会大面积复制数组，所以写的性能差，在写完成后将读的引用改为执行写的对象

Java中的锁

1，如何实现乐观锁（CAS）？如何避免ABA问题？

        1.CAS原语有三个值，一个是内存值，一个是期望值，一个是写入值。 在不加锁的情况下写入时，每次读取内存值，然后跟预期值比对，如果比对失败，反复的读和比对，直到成功。在CAS原语是一个原子操作，如果写入时，内存值发生改变，则写入值失败。
        2.带参数版本来避免aba问题，在读取和替换的时候进行判定版本是否一致

2，什么场景下可以使用volatile替换synchronized？
        只需要保证共享资源的可见性的时候可以使用volatile替代，synchronized保证可操作的原子性一致性和可见性。 volatile适用于新值不依赖于就值的情形

3，什么是可重入锁（ReentrantLock）？
ReentrantLock 相对于固有锁synchronized，同样是可重入的，在某些vm版本上提供了比固有锁更高的性能，提供了更丰富的锁特性，比如可中断的锁，可等待的锁，平等锁以及非块结构的加锁。从代码上尽量用固有锁，vm会对固有锁做一定的优化，并且代码可维护和稳定。只有在需要ReentrantLock的一些特性时，可以考虑用ReentrantLock实现。
4，ReentrantLock 和synchronized比较。来自《java并发编程实战》
1.为什么JUC框架出现LOCK？
ReentrantLock并不是替代synchronized的方法，而是当内置锁不适用时，作为一种可选的高级功能。
2.那么Synchronized有哪些缺点？
①. 只有一个condition与锁相关联，这个condition是什么？就是synchronized对针对的对象锁。
②. synchronized无法中断一个正在等待获得锁的线程，也即多线程竞争一个锁时，其余未得到锁的线程只能不停的尝试获得锁，而不能中断。这种情况对于大量的竞争线程会造成性能的下降等后果。
3.我们面对ReentrantLock和synchronized改如何选择？
Synchronized相比Lock，为许多开发人员所熟悉，并且简洁紧凑，如果现有程序已经使用了内置锁，那么尽量保持代码风格统一，尽量不引入Lock，避免两种机制混用，容易令人困惑，也容易发生错误。
在Synchronized无法满足需求的情况下，Lock可以作为一种高级工具，这些功能包括“可定时的、可轮询的与可中断的锁获取操作，公平队列，以及非块结构的锁”否则还是优先使用Synchronized。
最后，未来更可能提升Synchronized而不是Lock的性能，因为Synchronized是JVM的内置属性，他能执行一些优化，例如对线程封闭的锁对象的锁消除优化，通过增加锁的粒度来消除内置锁的同步，而如果基于类库的锁来实现这些功能，则可能性不大。

5，读写锁可以用于什么应用场景？(ReentrantReadWriteLock)

    区分读和写，处于读操作时，可以允许多个线程同时获得读操作。但是同一时刻只能有一个线程可以获得写锁。其它获取写锁失败的线程都会进入睡眠状态，直到写锁释放时被唤醒。 
注意：写锁会阻塞其它读写锁。当有一个线程获得写锁在写时，读锁也不能被其它线程获取；写优先于读，当有线程因为等待写锁而进入睡眠时，则后续读者也必须等待 
    适用于读取数据的频率远远大于写数据的频率的场合。 

6，什么时候应该使用可重入锁？

场景1：如果发现该操作已经在执行中则不再执行（有状态执行）

a、用在定时任务时，如果任务执行时间可能超过下次计划执行时间，确保该有状态任务只有一个正在执行，忽略重复触发。
b、用在界面交互时点击执行较长时间请求操作时，防止多次点击导致后台重复执行（忽略重复触发）。

以上两种情况多用于进行非重要任务防止重复执行，（如：清除无用临时文件，检查某些资源的可用性，数据备份操作等）

场景2：如果发现该操作已经在执行，等待一个一个执行（同步执行，类似synchronized）

这种比较常见大家也都在用，主要是防止资源使用冲突，保证同一时间内只有一个操作可以使用该资源。但与synchronized的明显区别是性能优势（伴随jvm的优化这个差距在减小）。同时Lock有更灵活的锁定方式，公平锁与不公平锁，而synchronized永远是公平的。

这种情况主要用于对资源的争抢（如：文件操作，同步消息发送，有状态的操作等）

ReentrantLock默认情况下为不公平锁

不公平锁与公平锁的区别：

公平情况下，操作会排一个队按顺序执行，来保证执行顺序。（会消耗更多的时间来排队）
不公平情况下，是无序状态允许插队，jvm会自动计算如何处理更快速来调度插队。（如果不关心顺序，这个速度会更快）

场景3：如果发现该操作已经在执行，则尝试等待一段时间，等待超时则不执行（尝试等待执行）

这种其实属于场景2的改进，等待获得锁的操作有一个时间的限制，如果超时则放弃执行。
用来防止由于资源处理不当长时间占用导致死锁情况（大家都在等待资源，导致线程队列溢出）

场景4：如果发现该操作已经在执行，等待执行。这时可中断正在进行的操作立刻释放锁继续下一操作。

synchronized与Lock在默认情况下是不会响应中断(interrupt)操作，会继续执行完。lockInterruptibly()提供了可中断锁来解决此问题。（场景2的另一种改进，没有超时，只能等待中断或执行完毕）

这种情况主要用于取消某些操作对资源的占用。如：（取消正在同步运行的操作，来防止不正常操作长时间占用造成的阻塞）

并发工具

1，如何实现一个流控程序，用于控制请求的调用次数？