java并发编程 英文_java并发编程(一) ：基础知识

首先使代码运行正确，然后再提高代码的速度。最好是当需求要求你提高性能的时候再进行优化，代码的正确性是第一保证。

线程安全性：当多个线程访问某个类时，这个类始终都能表现出正确的行为，那么就称这个类是线程安全的。(主调代码中不需要任何额外的同步或协同)

线程安全性的核心概念——正确性，即：某个类的行为与其规范完全一致。

前面说过，编写线程安全的代码核心在于，对状态访问操作进行管理。对于局部变量来说，计算过程仅存于当前线程栈上，不会被其他线程访问到，所以局部变量是无状态的。无状态的对象一定是线程安全的。

线程安全性要求：在多个线程之间的操作，无论采用何种执行时序或交替方式，都要保证不变性条件不被破坏。

(当在不变性条件中涉及多个变量时，各个变量之间并不是彼此独立的，它们互相之间会产生约束)

原子性：

同一组操作需要保持其原子性，与事务的原子性类似。如果一组操作是原子的，才能够保证他是线程安全的。

竞态条件：

两个或多个进程对共享的数据进行读或写的操作时，最终的结果取决于这些进程的执行顺序。(正确的结果取决于运气)

如：先检查后执行：基于一种可能已经失效的观察结果，来做过判断或计算。

示例：延迟初始化中的竞态条件

@NotThreadSafe

public class LaztInitRace {

private ExpensiveObject instance = null;

public ExpensiveObject getInstance(){

if(instance == null){

instance = new ExpensiveObject();

}

return instance;

}

}

//在本示例中，当B要判断instance是否为空时，要取决于不可预测的时序，

//包括线程的调度方式，以及A需要花多长时间来

//初始化ExpensiveObject并设置instance.

原子操作：

对于访问一个状态的所有操作来说，这个操作是以原子方式执行的操作。(要么执行完、要么不执行)

//当无状态的类中加入唯一个共享状态时，

//若这个共享状态交由线程安全的对象来管理，那么这个类仍然是线程安全的。

//要保持状态的一致性，就需要在单个原子操作中更新所有相关的状态变量。

内置锁(监视器锁)：

synchronized(lock){

//访问或修改由锁保护的共享状态

}

//线程在进入同步代码块之前会自动获得锁，并在退出同步代码块时自动释放锁。

java内置锁相当于一种互斥体：最多只有一个线程能持有这种锁。(无锁的线程必须等待或阻塞，直到锁被释放。如果锁不被占用着释放，它将永远等待下去)

所以：由这个锁保护的代码块会以原子方式执行，多个线程在执行该代码块时不会互相干扰。

重入机制：

如果某个线程试图获得一个自己已经持有的锁，那么这个请求就会成功。(锁的操作粒度是“线程”，而不是“调用”)

public class Widget {

public synchronized void doSomething(){

...

}

}

public  class loggingWidget extends Widget{

public synchronized void doSomething(){

super.doSomething(); //这里会再次请求锁，如果无法重入，将被锁死。

}

}

用锁来保护状态：

(确保不变性条件不被破坏)

锁能使其保护的代码路径以串行形式来访问。(实现对共享状态的独占访问)

注意：仅仅将复合操作封装到一个同步代码块是不够的。如果用同步来协调对某个变量的访问，那么访问这个变量的所有位置都需要使用同步。

一种常见的加锁约定：将所有的可变状态都封装在对象内部，并通过对象的内置锁对所有访问可变状态的代码路径进行同步，使得在该对象上不会发生并发访问。

//每个共享的和可变的变量都应该只由一个锁来保护。从而使维护人员知道是哪一个锁。

当类的不变性条件涉及多个变量时：在不变性条件中的每个变量都必须由同一个锁来保护。(在单个原子操作中访问和更新这些变量，以确保不变性条件不被破坏。)

活跃性与性能：

可同时调用的数量，不仅受到可用处理资源的限制，还要受到应用程序本身结构的限制。

避免不良并发：

1：缩小同步代码块的范围，但不要过小("足够小")。(并且，不要将本应是院子的操作拆分到多个同步代码块中，应尽量将不影响共享状态、且执行时间较长的操作移除同步代码块)

判断同步代码块的合理大小，需要在各种设计需求之间进行平衡：安全性(必须满足)、简单性、性能。

通常，简单性与性能之间存在着互相制约的因素。

在实现某个同步策略时，一定不要盲目地为了性能而牺牲简单性，这样做有可能破坏安全性。

在执行时间较长的计算或可能无法快速完成的操作时，一定不要持有锁(如：网络I/O、控制台I/O)