并发编程一

一、并发和并行：
并发是同一时间应对(dealing with)多件事情的能力；
并行是同一时间做(doing)多件事情的能力。

二、并行架构：
位级并行，32位计算机的运行速度比8位计算机更快，因为并行，对于32位数的加法，8位计算机必须进行多次8位计算，而32位计算机可以一步完成，即并行的处理32位的4字节。
指令级(instruction-level)并行，程序员通常可以不关心处理器内部并行的细节，因为尽管处理器内部的并行度很高，但是经过精心设计，从外部看上去所有处理都像是串行的。
数据级(data)并行,数据级并行(也称为“单指令多数据”，SIMD)架构，可以并行地在大量数据上施加同一操作。这并不适合解决所有问题，但在适合的场景却可以大展身手。
任务级(task-level)并行，终于来到了大家所认为的并行形式——多处理器。从程序员的角度来看，多处理器架构最明 显的分类特征是其内存模型(共享内存模型或分布式内存模型)。

对于共享内存的多处理器系统，每个处理器都能访问整个内存，处理器之间的通信主要通过内存进行。
对于分布式内存的多处理器系统，每个处理器都有自己的内存，处理器之间的通信主要通过网络进行。
用并发的目的，不仅仅是为了让程序并行运行从而发挥多核的优势。若正确使用并发，程序还将获得以下优点:及时响应、高效、容错、简单。

注意：不应该在产品代码上，使用Thread类等底层服务。

三、七个模型

1、线程与锁:线程与锁模型有很多众所周知的不足，但仍是其他模型的技术基础，也是很多并 发软件开发的首选。
2、函数式编程:函数式编程日渐重要的原因之一，是其对并发编程和并行编程提供了良好的支 持。函数式编程消除了可变状态，所以从根本上是线程安全的，而且易于并行执行。
3、Clojure之道——分离标识与状态:编程语言Clojure是一种指令式编程和函数式编程的混搭方 案，在两种编程方式上取得了微妙的平衡来发挥两者的优势。
4、actor:actor模型是一种适用性很广的并发编程模型，适用于共享内存模型和分布式内存模型， 也适合解决地理分布型问题，能提供强大的容错性。
5、通信顺序进程(Communicating Sequential Processes，CSP):表面上看，CSP模型与actor模 型很相似，两者都基于消息传递。不过CSP模型侧重于传递信息的通道，而actor模型侧重于通道 两端的实体，使用CSP模型的代码会带有明显不同的风格。
6、数据级并行:每个笔记本电脑里都藏着一台超级计算机——GPU。GPU利用了数据级并行， 不仅可以快速进行图像处理，也可以用于更广阔的领域。如果要进行有限元分析、流体力学计算 或其他的大量数字计算，GPU的性能将是不二选择。
7、Lambda架构:大数据时代的到来离不开并行——现在我们只需要增加计算资源，就能具有 处理TB级数据的能力。Lambda架构综合了MapReduce和流式处理的特点，是一种可以处理多种大数据问题的架构。

四、线程与锁：

  class Counter {
    private int count = 0;
    public synchronized void increment() {
        ++count; 
    } 
    public int getCount() {
        return count; 
    }
}

毋庸置疑，对于增加了同步功能的代码，每次执行都将得到正确结果，但代码中仍隐藏了一个bug。
潜藏的bug是:
除了increment()之外，getCount()方法 也需要进行同步。
否则，当一个线程对值的修改没有及时更新到主内存，从而导致
调用getCount()的线程可能获得一个失效的值。
解释：
Java内存模型定义了何时一个线程对内存的修改对另一个线程可见。
基本原则是，如果读 线程和写线程不进行同步，就不能保证可见性。
然而两个线程都需要进行同步。只在其中一个线程进行同步是不够的，

竞态条件：
  计算的正确性取决于多个线程的交替执行时序时，就会发生竞态条件。
    
    1、乱序执行。执行依赖于检测的结果，而检测结果依赖于多个线程的执行时序。
    乱序原因：
     编译器的静态优化可以打乱代码的执行顺序;
     JVM的动态优化也会打乱代码的执行顺序; 
     硬件可以通过乱序执行来优化其性能。
    

所以在多线程环境下，对一个文件的操作需要加锁。

2、延迟初始化：
线程A和线程B同时执行getInstance，可能会取到两个实例对象，主要看线程执行时序了。

public class ObjFactory {  
    private Obj instance;  
      
    public Obj getInstance(){  
        if(instance == null){  
            instance = new Obj();  
        }  
        return instance;  
    }  
}

五、来自外星方法的危害

规模较大的程序常用监听器模式(listener)来解耦模块。
在这里，我们构造一个类从一个URL 进行下载，并用ProgressListeners监听下载的进度。
 
 public class Downloader extends Thread {

private InputStream in;
private OutputStream out;
private ArrayList<ProgressListener> listeners;

public Downloader(URL url,String outputFilename) throws IOException {
    in=url.openConnection().getInputStream();
    out = new FileOutputStream(outputFilename);
    listeners=new ArrayList<ProgressListener>();
}

public synchronized void addListener(ProgressListener listener){
    listeners.add(listener);
}
public synchronized boolean remove(ProgressListener listener){
   return listeners.remove(listener);
}

/***
 * 来自外星方法的危害
 *
 * addListener()、removeListener()和updateProgress()都是同步方法，
 * 多线程可以安全地使用这些方法。尽管这段代码仅使用了一把锁，但仍隐藏着一个死锁陷阱。
 *
 * 陷阱在于updateProgress()调用了一个外星方法——但对于这个外星方法一无所知。外星方法可以做任何事情，
 * 例如持有另外一把锁。这样一来，我们就在对加锁顺序一无所知的情况下使用了两把锁。就像前面提到的，这就有可能发生死锁。
 *
 * @param n
 */
private synchronized void updateProgress(int n){
    for(ProgressListener listener:listeners){
        listener.onProgress(n);
    }
}

/***
 *  一种方法是在遍历之前对listeners进行保 护性复制(defensive copy)，
 *  再针对这份副本进行遍历
 *  这是个一石多鸟的方法。不仅在调用外星方法时不用加锁，而且大大减少了代码持有锁的时间。
 *  长时间地持有锁将影响性能(降低了程序的并发度)，也会增加死锁的可能。
 * @param n
 */
private void updateProgress2(int n){
        ArrayList<ProgressListener> listenersCopy=null;
        synchronized (this){
            listenersCopy=(ArrayList<ProgressListener> )listeners.clone();
        }
        for(ProgressListener listener:listenersCopy){
            listener.onProgress(n);
        }


    }

    @Override
    public void run(){
        int n = 0, total = 0;
        byte[] buffer = new byte[1024];
        try {
            while((n = in.read(buffer)) != -1) {
                out.write(buffer, 0, n);
                total += n;
                updateProgress(total);
            }
            out.flush();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

}