JAVA基础-多线程
程序、进程、线程
程序：由高级语言编写，然后在编译的过程中，被编译器/解释器转译为机器语言，从而得以执行
顺序执行时的主要特征包括顺序行，封闭性，可再现性
进程：进程是程序的一次执行，该程序可以和其他程序并发执行。是系统进行资源分配和调用的独立单位。每一个进程都有它自己的内存空间和系统资源。
进程是由程序、数据和进程控制块组成。
线程：是程序的执行单元，执行路径。是程序使用CPU的最基本单位。
是进程中的单个顺序控制流，是一条执行路径
一个进程如果只有一条执行路径，则称为单线程程序。
一个进程如果有多条执行路径，则称为多线程程序。
线程生命周期图解
线程的生命周期有五种状态：
新建状态(new)：当一个线程类实例被创建时，线程处于新建状态，此时的线程已经被初始化，并分配了资源
就绪状态(Runnable)：已具备运行条件，进入线程队列，排队等待CPU。一旦获得CPU使用权，就可进入运行状态
运行状态(Running)：当处于就绪状态的线程被调度获得CPU资源时，就进入了运行状态。定义在线程体中的run()方法被调用，从方法体的第一条语句开始顺序执行；
阻塞状态(Blocked)：处于运行状态的线程因事件的发生，而导致让出CPU使用权，并终止当前执行，进行阻塞状态。
例如：Thread myThread = new MyThreadClass( );
例如：myThread.start( );
多线程有什么意义
多线程的存在，不是提高程序的执行速度。其实是为了提高应用程序的使用率。
程序的执行其实都是在抢CPU的资源，CPU的执行权。
多个进程是在抢这个资源，而其中的某一个进程如果执行路径比较多，就会有更高的几率抢到CPU的执行权。
我们是不敢保证哪一个线程能够在哪个时刻抢到，所以线程的执行有随机性。
多线程的代价
设计更复杂
虽然有一些多线程应用程序比单线程的应用程序要简单，但其他的一般都更复杂。在多线程访问共享数据的时候，这部分代码需要特别的注意。线程之间的交互往往非常复杂。不正确的线程同步产生的错误非常难以被发现，并且重现以修复。
上下文切换的开销
当CPU从执行一个线程切换到执行另外一个线程的时候，它需要先存储当前线程的本地的数据，程序指针等，然后载入另一个线程的本地数据，程序指针 等，最后才开始执行。这种切换称为“上下文切换”(“context switch”)。CPU会在一个上下文中执行一个线程，然后切换到另外一个上下文中执行另外一个线程。
增加资源消耗
线程在运行的时候需要从计算机里面得到一些资源。除了CPU，线程还需要一些内存来维持它本地的堆栈。它也需要占用操作系统中一些资源来管理线程。
线程的优先级
Java中Thread对象有一个优先级的概念，优先级被划分10个级别，创建线程的时候，如果没有指定优先级，默认是5。主线程的优先级也是5。优先级高的线程会比优先级低的线程获得更多的运行机会。
Thread类定义了3个整形常量MAX_PRIORITY、NORM_PRIORITY、MIN_PRIORITY分别用于表示支持的最高优先级，正常优先级和最低优先级。同时提供了一个getPriority()方法来获取当前线程优先级。
public class PriorityDemo {
public static void main(String[] args) {
System.out.println("最大优先级;"+Thread.MAX_PRIORITY);
System.out.println("正常优先级;"+Thread.NORM_PRIORITY);
System.out.println("最小优先级;"+Thread.MIN_PRIORITY);
System.out.println("主线程优先级;"+Thread.currentThread().getPriority());
Thread t=new Thread();
System.out.println("创建一个线程默认的优先级:"+t.getPriority());
}
}
类 Thread
public class Thread extends Object implements Runnable
线程 是程序中的执行线程。Java 虚拟机允许应用程序并发地运行多个执行线程。
每个线程都有一个优先级，高优先级线程的执行优先于低优先级线程。每个线程都可以或不可以标记为一个守护程序。当某个线程中运行的代码创建一个新 Thread 对象时，该新线程的初始优先级被设定为创建线程的优先级，并且当且仅当创建线程是守护线程时，新线程才是守护程序。
当 Java 虚拟机启动时，通常都会有单个非守护线程（它通常会调用某个指定类的 main 方法）。Java
虚拟机会继续执行线程，直到下列任一情况出现时为止：
- 调用了 Runtime 类的 exit 方法，并且安全管理器允许退出操作发生。
- 非守护线程的所有线程都已停止运行，无论是通过从对 run 方法的调用中返回，还是通过抛出一个传播到 run 方法之外的异常。
创建新执行线程有两种方法。一种方法是将类声明为 Thread 的子类。该子类应重写 Thread 类的 run 方法。接下来可以分配并启动该子类的实例。例如，计算大于某一规定值的质数的线程可以写成：
class PrimeThread extends Thread {
long minPrime;
PrimeThread(long minPrime) {
this.minPrime = minPrime;
}
public void run() {
// compute primes larger than minPrime
. . .
}
}
然后，下列代码会创建并启动一个线程：
PrimeThread p = new PrimeThread(143);
p.start();
|
方法摘要 |
|
|
static int |
activeCount() 返回当前线程的线程组中活动线程的数目。 |
|
void |
checkAccess() 判定当前运行的线程是否有权修改该线程。 |
|
int |
countStackFrames() 已过时。 该调用的定义依赖于 suspend()，但它遭到了反对。此外，该调用的结果从来都不是意义明确的。 |
|
static Thread |
currentThread() 返回对当前正在执行的线程对象的引用。 |
|
void |
destroy() 已过时。 该方法最初用于破坏该线程，但不作任何清除。它所保持的任何监视器都会保持锁定状态。不过，该方法决不会被实现。即使要实现，它也极有可能以 suspend() 方式被死锁。如果目标线程被破坏时保持一个保护关键系统资源的锁，则任何线程在任何时候都无法再次访问该资源。如果另一个线程曾试图锁定该资源，则会出现死锁。这类死锁通常会证明它们自己是“冻结”的进程。有关更多信息，请参阅为何不赞成使用 Thread.stop、Thread.suspend 和 Thread.resume？。 |
|
static void |
dumpStack() 将当前线程的堆栈跟踪打印至标准错误流。 |
|
static int |
enumerate(Thread[] tarray) 将当前线程的线程组及其子组中的每一个活动线程复制到指定的数组中。 |
|
static Map<Thread,StackTraceElement[]> |
getAllStackTraces() 返回所有活动线程的堆栈跟踪的一个映射。 |
|
ClassLoader |
getContextClassLoader() 返回该线程的上下文 ClassLoader。 |
|
static Thread.UncaughtExceptionHandler |
getDefaultUncaughtExceptionHandler() 返回线程由于未捕获到异常而突然终止时调用的默认处理程序。 |
|
long |
getId() 返回该线程的标识符。 |
|
String |
getName() 返回该线程的名称。 |
|
int |
getPriority() 返回线程的优先级。 |
|
StackTraceElement[] |
getStackTrace() 返回一个表示该线程堆栈转储的堆栈跟踪元素数组。 |
|
Thread.State |
getState() 返回该线程的状态。 |
|
ThreadGroup |
getThreadGroup() 返回该线程所属的线程组。 |
|
Thread.UncaughtExceptionHandler |
getUncaughtExceptionHandler() 返回该线程由于未捕获到异常而突然终止时调用的处理程序。 |
|
static boolean |
holdsLock(Object obj) 当且仅当当前线程在指定的对象上保持监视器锁时，才返回 true。 |
|
void |
interrupt() 中断线程。 |
|
static boolean |
interrupted() 测试当前线程是否已经中断。 |
|
boolean |
isAlive() 测试线程是否处于活动状态。 |
|
boolean |
isDaemon() 测试该线程是否为守护线程。 |
|
boolean |
isInterrupted() 测试线程是否已经中断。 |
|
void |
join() 等待该线程终止。 |
|
void |
join(long millis) 等待该线程终止的时间最长为 millis 毫秒。 |
|
void |
join(long millis, int nanos) 等待该线程终止的时间最长为 millis 毫秒 + nanos 纳秒。 |
|
void |
resume() 已过时。 该方法只与 suspend() 一起使用，但 suspend() 已经遭到反对，因为它具有死锁倾向。有关更多信息，请参阅为何不赞成使用 Thread.stop、Thread.suspend 和 Thread.resume？。 |
|
void |
run() 如果该线程是使用独立的 Runnable 运行对象构造的，则调用该 Runnable 对象的 run 方法；否则，该方法不执行任何操作并返回。 |
|
void |
setContextClassLoader(ClassLoader cl) 设置该线程的上下文 ClassLoader。 |
|
void |
setDaemon(boolean on) 将该线程标记为守护线程或用户线程。 |
|
static void |
setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh) 设置当线程由于未捕获到异常而突然终止，并且没有为该线程定义其他处理程序时所调用的默认处理程序。 |
|
void |
setName(String name) 改变线程名称，使之与参数 name 相同。 |
|
void |
setPriority(int newPriority) 更改线程的优先级。 |
|
void |
setUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh) 设置该线程由于未捕获到异常而突然终止时调用的处理程序。 |
|
static void |
sleep(long millis) 在指定的毫秒数内让当前正在执行的线程休眠（暂停执行），此操作受到系统计时器和调度程序精度和准确性的影响。 |
|
static void |
sleep(long millis, int nanos) 在指定的毫秒数加指定的纳秒数内让当前正在执行的线程休眠（暂停执行），此操作受到系统计时器和调度程序精度和准确性的影响。 |
|
void |
start() 使该线程开始执行；Java 虚拟机调用该线程的 run 方法。 |
|
void |
stop() 已过时。 该方法具有固有的不安全性。用 Thread.stop 来终止线程将释放它已经锁定的所有监视器（作为沿堆栈向上传播的未检查 ThreadDeath 异常的一个自然后果）。如果以前受这些监视器保护的任何对象都处于一种不一致的状态，则损坏的对象将对其他线程可见，这有可能导致任意的行为。stop 的许多使用都应由只修改某些变量以指示目标线程应该停止运行的代码来取代。目标线程应定期检查该变量，并且如果该变量指示它要停止运行，则从其运行方法依次返回。如果目标线程等待很长时间（例如基于一个条件变量），则应使用 interrupt 方法来中断该等待。有关更多信息，请参阅为何不赞成使用 Thread.stop、Thread.suspend 和 Thread.resume？。 |
|
void |
stop(Throwable obj) 已过时。 该方法具有固有的不安全性。有关详细信息，请参阅 stop()。该方法的附加危险是它可用于生成目标线程未准备处理的异常（包括若没有该方法该线程不太可能抛出的已检查的异常）。有关更多信息，请参阅为何不赞成使用 Thread.stop、Thread.suspend 和 Thread.resume？。 |
|
void |
suspend() 已过时。 该方法已经遭到反对，因为它具有固有的死锁倾向。如果目标线程挂起时在保护关键系统资源的监视器上保持有锁，则在目标线程重新开始以前任何线程都不能访问该资源。如果重新开始目标线程的线程想在调用 resume 之前锁定该监视器，则会发生死锁。这类死锁通常会证明自己是“冻结”的进程。有关更多信息，请参阅为何不赞成使用 Thread.stop、Thread.suspend 和 Thread.resume？。 |
|
String |
toString() 返回该线程的字符串表示形式，包括线程名称、优先级和线程组。 |
|
static void |
yield() 暂停当前正在执行的线程对象，并执行其他线程。 |
接口 Runnable
public interface Runnable
Runnable 接口应该由那些打算通过某一线程执行其实例的类来实现。类必须定义一个称为 run
的无参数方法。
设计该接口的目的是为希望在活动时执行代码的对象提供一个公共协议。例如，Thread 类实现了 Runnable。激活的意思是说某个线程已启动并且尚未停止。
此外，Runnable 为非 Thread 子类的类提供了一种激活方式。通过实例化某个 Thread 实例并将自身作为运行目标，就可以运行实现 Runnable 的类而无需创建 Thread 的子类。大多数情况下，如果只想重写 run() 方法，而不重写其他 Thread 方法，那么应使用 Runnable
接口。这很重要，因为除非程序员打算修改或增强类的基本行为，否则不应为该类创建子类。
接口 Callable<V>
public interface Callable<V>
返回结果并且可能抛出异常的任务。实现者定义了一个不带任何参数的叫做 call 的方法。
Callable 接口类似于 Runnable，两者都是为那些其实例可能被另一个线程执行的类设计的。但是 Runnable 不会返回结果，并且无法抛出经过检查的异常。
Executors
类包含一些从其他普通形式转换成 Callable 类的实用方法。
|
参数类型为 Callable 的 java.util.concurrent 中的构造方法 |
|
|
FutureTask(Callable<V> callable) 创建一个 FutureTask，一旦运行就执行给定的 Callable。 |
接口 Future<V>
类型参数：V - 此 Future 的 get 方法所返回的结果类型所有已知子接口： Response<T>, RunnableFuture<V>, RunnableScheduledFuture<V>, ScheduledFuture<V> 所有已知实现类： FutureTask, SwingWorker
public interface Future<V>
Future 表示异步计算的结果。它提供了检查计算是否完成的方法，以等待计算的完成，并获取计算的结果。计算完成后只能使用 get 方法来获取结果，如有必要，计算完成前可以阻塞此方法。取消则由 cancel
方法来执行。还提供了其他方法，以确定任务是正常完成还是被取消了。一旦计算完成，就不能再取消计算。如果为了可取消性而使用 Future
但又不提供可用的结果，则可以声明 Future<?> 形式类型、并返回 null 作为底层任务的结果。
用法示例（注意，下列各类都是构造好的。）
interface ArchiveSearcher { String search(String target); }
class App {
ExecutorService executor = ...
ArchiveSearcher searcher = ...
void showSearch(final String target)
throws InterruptedException {
Future<String> future
= executor.submit(new Callable<String>() {
public String call() {
return searcher.search(target);
}});
displayOtherThings(); // do other things while searching
try {
displayText(future.get()); // use future
} catch (ExecutionException ex) { cleanup(); return; }
}
}
FutureTask
类是 Future 的一个实现，Future 可实现 Runnable，所以可通过 Executor 来执行。例如，可用下列内容替换上面带有 submit 的构造：
FutureTask<String> future =
new FutureTask<String>(new Callable<String>() {
public String call() {
return searcher.search(target);
}});
executor.execute(future);
第一个submit方法里面的参数类型就是Callable。
暂时只需要知道Callable一般是和ExecutorService配合来使用的，具体的使用方法讲在后面讲述。
一般情况下我们使用第一个submit方法和第三个submit方法，第二个submit方法很少使用。
public class CallableAndFuture {
public static void main(String[] args) {
System.out.println("开始时间:" + new Date());
ExecutorService service = Executors.newSingleThreadExecutor();
//Future与Callable中的泛型，就是返回值的类型
Future<String> future = service.submit(new Callable<String>() {
public String call() throws Exception {
Thread.sleep(2000);
return "Hello";
}
});
try {
String result = future.get();// 该方法会进行阻塞，等待执行完成
System.out.println(result);
} catch (Exception e) {
e.printStackTrace();
}
System.out.println("结束时间:" + new Date());
service.shutdown();
}
}
线程安全的类
StringBuffer sb = new StringBuffer();
Vector<String> v = new Vector<String>();
Hashtable<String, String> h = new Hashtable<String, String>();
线程池的方法创建多线程
为什么要使用线程池？
在java中，如果每个请求到达就创建一个新线程，开销是相当大的。在实际使用中，创建和销毁线程花费的时间和消耗的系统资源都相当大，甚至可能要比在处理实际的用户请求的时间和资源要多的多。除了创建和销毁线程的开销之外，活动的线程也需要消耗系统资源。如果在一个jvm里创建太多的线程，可能会使系统由于过度消耗内存或“切换过度”而导致系统资源不足。为了防止资源不足，需要采取一些办法来限制任何给定时刻处理的请求数目，尽可能减少创建和销毁线程的次数，特别是一些资源耗费比较大的线程的创建和销毁，尽量利用已有对象来进行服务。
线程池主要用来解决线程生命周期开销问题和资源不足问题。通过对多个任务重复使用线程，线程创建的开销就被分摊到了多个任务上了，而且由于在请求到达时线程已经存在，所以消除了线程创建所带来的延迟。这样，就可以立即为请求服务，使用应用程序响应更快。另外，通过适当的调整线程中的线程数目可以防止出现资源不足的情况。
线程池的任务处理策略
如果当前线程池中的线程数目小于corePoolSize，则每来一个任务，就会分配一个线程去执行这个任务；
如果当前线程池中的线程数目>=corePoolSize，则每来一个任务，会尝试将其添加到任务缓存队列当中，若添加成功，则该任务会等待空闲线程将其取出去执行；若添加失败（一般来说是任务缓存队列已满），则会尝试创建新的线程去执行这个任务；如果当前线程池中的线程数目达到maximumPoolSize，则会采取任务拒绝策略进行处理；
如果线程池中的线程数量大于 corePoolSize时，此时若某线程空闲时间超过keepAliveTime，该线程将被终止，直至线程池中的线程数目不大于corePoolSize；如果允许为核心池中的线程设置存活时间，那么核心池中的线程空闲时间超过keepAliveTime，线程也会被终止。
使用线程池创建多线程的优点
减少了创建新线程的时间，提高程序的响应速度
重复利用线程池中的线程，不需要每次都创建新的线程降低资源消耗
便于线程的管理：
corePoolSize:表示允许线程池中允许同时运行的最大线程数
maximumPoolSize:线程池允许的最大线程数，他表示最大能创建多少个线程。maximumPoolSize肯定是大于等于corePoolSize
KeepAliveTime:表示线程没有任务时最多保持多久然后停止
接口 ExecutorService
所有超级接口： Executor
所有已知子接口： ScheduledExecutorService
所有已知实现类： AbstractExecutorService, ScheduledThreadPoolExecutor, ThreadPoolExecutor
public interface ExecutorServiceextends Executor
Executor
提供了管理终止的方法，以及可为跟踪一个或多个异步任务执行状况而生成 Future 的方法。
可以关闭 ExecutorService，这将导致其拒绝新任务。提供两个方法来关闭 ExecutorService。shutdown()
方法在终止前允许执行以前提交的任务，而 shutdownNow()
方法阻止等待任务启动并试图停止当前正在执行的任务。在终止时，执行程序没有任务在执行，也没有任务在等待执行，并且无法提交新任务。应该关闭未使用的 ExecutorService 以允许回收其资源。
通过创建并返回一个可用于取消执行和/或等待完成的 Future，方法 submit 扩展了基本方法 Executor.execute(java.lang.Runnable)。方法 invokeAny 和 invokeAll 是批量执行的最常用形式，它们执行任务
collection，然后等待至少一个，或全部任务完成（可使用 ExecutorCompletionService
类来编写这些方法的自定义变体）。
Executors
类提供了用于此包中所提供的执行程序服务的工厂方法。
//1、先创建一个线程池
ExecutorService executorService = Executors.newFixedThreadPool(10);
//3、为线程池中线程分配任务并执行
ThreadPoolExecutor threadPoolExecutor=(ThreadPoolExecutor)executorService;
class NetworkService implements Runnable {
private final ServerSocket serverSocket;
private final ExecutorService pool;
public NetworkService(int port, int poolSize)
throws IOException {
serverSocket = new ServerSocket(port);
pool = Executors.newFixedThreadPool(poolSize);
}
public void run() { // run the service
try {
for (;;) {
pool.execute(new Handler(serverSocket.accept()));
}
} catch (IOException ex) {
pool.shutdown();
}
}
}
class Handler implements Runnable {
private final Socket socket;
Handler(Socket socket) { this.socket = socket; }
public void run() {
// read and service request on socket
}
}
使用线程池方式--Runnable接口
通常，线程池都是通过线程池工厂创建，再调用线程池中的方法获取线程，再通过线程去执行任务方法。
l Executors：线程池创建工厂类
l public static ExecutorService newFixedThreadPool(int nThreads)：返回线程池对象
l ExecutorService：线程池类
l Future<?> submit(Runnable task)：获取线程池中的某一个线程对象，并执行
l Future接口：用来记录线程任务执行完毕后产生的结果。线程池创建与使用
//创建线程池对象
ExecutorService service = Executors.newFixedThreadPool(2);//包含2个线程对象
//创建Runnable实例对象
MyRunnable r = new MyRunnable();
//自己创建线程对象的方式
//Thread t = new Thread(r);
//t.start(); ---> 调用MyRunnable中的run()
//从线程池中获取线程对象,然后调用MyRunnable中的run()
service.submit(r);
//再获取个线程对象，调用MyRunnable中的run()
service.submit(r);
service.submit(r);
//注意：submit方法调用结束后，程序并不终止，是因为线程池控制了线程的关闭。将使用完的线程又归还到了线程池中
//关闭线程池
//service.shutdown();
使用线程池方式—Callable接口
l Callable接口：与Runnable接口功能相似，用来指定线程的任务。其中的call()方法，用来返回线程任务执行完毕后的结果，call方法可抛出异常。
l ExecutorService：线程池类
l <T> Future<T> submit(Callable<T> task)：获取线程池中的某一个线程对象，并执行线程中的call()方法
l Future接口：用来记录线程任务执行完毕后产生的结果。线程池创建与使用
l 使用线程池中线程对象的步骤：
l 创建线程池对象
l 创建Callable接口子类对象
l 提交Callable接口子类对象
l 关闭线程池
//创建线程池对象
ExecutorService service = Executors.newFixedThreadPool(2);//包含2个线程对象
//创建Callable对象
MyCallable c = new MyCallable();
//从线程池中获取线程对象,然后调用MyRunnable中的run()
service.submit(c);
//注意：submit方法调用结束后，程序并不终止，是因为线程池控制了线程的关闭。将使用完的线程又归还到了线程池中
//关闭线程池
//service.shutdown();
public class ThreadPoolDemo {
public static void main(String[] args) throws InterruptedException, ExecutionException {
//创建线程池对象
ExecutorService threadPool = Executors.newFixedThreadPool(2);
//创建一个Callable接口子类对象
//MyCallable c = new MyCallable();
MyCallable c = new MyCallable(100, 200);
MyCallable c2 = new MyCallable(10, 20);
//获取线程池中的线程，调用Callable接口子类对象中的call()方法, 完成求和操作
//<Integer> Future<Integer> submit(Callable<Integer> task)
// Future 结果对象
Future<Integer> result = threadPool.submit(c);
//此 Future 的 get 方法所返回的结果类型
Integer sum = result.get();
System.out.println("sum=" + sum);
result = threadPool.submit(c2);
sum = result.get();
System.out.println("sum=" + sum);
//关闭线程池(可以不关闭)
}
}
并发编程模型
并发模型与分布式系统之间的相似性
本文所描述的并发模型类似于分布式系统中使用的很多体系结构。在并发系统中线程之间可以相互通信。在分布式系统中进程之间也可以相互通信（进程有可能在不同的机器中）。线程和进程之间具有很多相似的特性。这也就是为什么很多并发模型通常类似于各种分布式系统架构。
当然，分布式系统在处理网络失效、远程主机或进程宕掉等方面也面临着额外的挑战。但是运行在巨型服务器上的并发系统也可能遇到类似的问题，比如一块CPU失效、一块网卡失效或一个磁盘损坏等情况。虽然出现失效的概率可能很低，但是在理论上仍然有可能发生。
由于并发模型类似于分布式系统架构，因此它们通常可以互相借鉴思想。例如，为工作者们（线程）分配作业的模型一般与分布式系统中的负载均衡系统比较相似。同样，它们在日志记录、失效转移、幂等性等错误处理技术上也具有相似性。
并行工作者模型
在并行工作者模型中，委派者（Delegator）将传入的作业分配给不同的工作者。每个工作者完成整个任务。工作者们并行运作在不同的线程上，甚至可能在不同的CPU上。
并行工作者模型的优点
并行工作者模式的优点是，它很容易理解。你只需添加更多的工作者来提高系统的并行度。
例如，如果你正在做一个网络爬虫，可以试试使用不同数量的工作者抓取到一定数量的页面，然后看看多少数量的工作者消耗的时间最短（意味着性能最 高）。由于网络爬虫是一个IO密集型工作，最终结果很有可能是你电脑中的每个CPU或核心分配了几个线程。每个CPU若只分配一个线程可能有点少，因为在 等待数据下载的过程中CPU将会空闲大量时间。
并行工作者模型的缺点
并行工作者模型虽然看起来简单，却隐藏着一些缺点。接下来的章节中我会分析一些最明显的弱点。
1)共享状态可能会很复杂
在实际应用中，并行工作者模型可能比前面所描述的情况要复杂得多。共享的工作者经常需要访问一些共享数据，无论是内存中的或者共享的数据库中的。下图展示了并行工作者模型是如何变得复杂的：
2)无状态的工作者
共享状态能够被系统中得其他线程修改。所以工作者在每次需要的时候必须重读状态，以确保每次都能访问到最新的副本，不管共享状态是保存在内存中的还是在外部数据库中。工作者无法在内部保存这个状态（但是每次需要的时候可以重读）称为无状态的。每次都重读需要的数据，将会导致速度变慢，特别是状态保存在外部数据库中的时候。
3)任务顺序是不确定的
并行工作者模式的另一个缺点是，作业执行顺序是不确定的。无法保证哪个作业最先或者最后被执行。作业A可能在作业B之前就被分配工作者了，但是作业B反而有可能在作业A之前执行。
并行工作者模式的这种非确定性的特性，使得很难在任何特定的时间点推断系统的状态。这也使得它也更难（如果不是不可能的话）保证一个作业在其他作业之前被执行。
流水线模型
第二种并发模型我们称之为流水线并发模型。我之所以选用这个名字，只是为了配合“并行工作者”的隐喻。其他开发者可能会根据平台或社区选择其他称呼（比如说反应器系统，或事件驱动系统）。下图表示一个流水线并发模型：
类似于工厂中生产线上的工人们那样组织工作者。每个工作者只负责作业中的部分工作。当完成了自己的这部分工作时工作者会将作业转发给下一个工作者。每个工作者在自己的线程中运行，并且不会和其他工作者共享状态。有时也被称为无共享并行模型。
通常使用非阻塞的IO来设计使用流水线并发模型的系统。非阻塞IO意味着，一旦某个工作者开始一个IO操作的时候（比如读取文件或从网络连接中读取 数据），这个工作者不会一直等待IO操作的结束。IO操作速度很慢，所以等待IO操作结束很浪费CPU时间。此时CPU可以做一些其他事情。当IO操作完 成的时候，IO操作的结果（比如读出的数据或者数据写完的状态）被传递给下一个工作者。
有了非阻塞IO，就可以使用IO操作确定工作者之间的边界。工作者会尽可能多运行直到遇到并启动一个IO操作。然后交出作业的控制权。当IO操作完成的时候，在流水线上的下一个工作者继续进行操作，直到它也遇到并启动一个IO操作。
在实际应用中，作业有可能不会沿着单一流水线进行。由于大多数系统可以执行多个作业，作业从一个工作者流向另一个工作者取决于作业需要做的工作。在实际中可能会有多个不同的虚拟流水线同时运行。这是现实当中作业在流水线系统中可能的移动情况：
作业甚至也有可能被转发到超过一个工作者上并发处理。比如说，作业有可能被同时转发到作业执行器和作业日志器。下图说明了三条流水线是如何通过将作业转发给同一个工作者（中间流水线的最后一个工作者）来完成作业:
流水线有时候比这个情况更加复杂。
反应器，事件驱动系统
采用流水线并发模型的系统有时候也称为反应器系统或事件驱动系统。系统内的工作者对系统内出现的事件做出反应，这些事件也有可能来自于外部世界或者 发自其他工作者。事件可以是传入的HTTP请求，也可以是某个文件成功加载到内存中等。在写这篇文章的时候，已经有很多有趣的反应器/事件驱动平台可以使 用了，并且不久的将来会有更多。比较流行的似乎是这几个：
* Vert.x
* AKKa
* Node.JS(JavaScript)
我个人觉得Vert.x是相当有趣的（特别是对于我这样使用Java/JVM的人来说）
Actors 和 Channels
Actors 和 channels 是两种比较类似的流水线（或反应器/事件驱动）模型。
在Actor模型中每个工作者被称为actor。Actor之间可以直接异步地发送和处理消息。Actor可以被用来实现一个或多个像前文描述的那样的作业处理流水线。下图给出了Actor模型：
而在Channel模型中，工作者之间不直接进行通信。相反，它们在不同的通道中发布自己的消息（事件）。其他工作者们可以在这些通道上监听消息，发送者无需知道谁在监听。下图给出了Channel模型：
在写这篇文章的时候，channel模型对于我来说似乎更加灵活。一个工作者无需知道谁在后面的流水线上处理作业。只需知道作业（或消息等）需要转 发给哪个通道。通道上的监听者可以随意订阅或者取消订阅，并不会影响向这个通道发送消息的工作者。这使得工作者之间具有松散的耦合。
流水线模型的优点
相比并行工作者模型，流水线并发模型具有几个优点，在接下来的章节中我会介绍几个最大的优点。
1)无需共享的状态
工作者之间无需共享状态，意味着实现的时候无需考虑所有因并发访问共享对象而产生的并发性问题。这使得在实现工作者的时候变得非常容易。在实现工作者的时候就好像是单个线程在处理工作-基本上是一个单线程的实现。
2)有状态的工作者
当工作者知道了没有其他线程可以修改它们的数据，工作者可以变成有状态的。对于有状态，我是指，它们可以在内存中保存它们需要操作的数据，只需在最后将更改写回到外部存储系统。因此，有状态的工作者通常比无状态的工作者具有更高的性能。
3)较好的硬件整合（Hardware Conformity）
单线程代码在整合底层硬件的时候往往具有更好的优势。首先，当能确定代码只在单线程模式下执行的时候，通常能够创建更优化的数据结构和算法。
其次，像前文描述的那样，单线程有状态的工作者能够在内存中缓存数据。在内存中缓存数据的同时，也意味着数据很有可能也缓存在执行这个线程的CPU的缓存中。这使得访问缓存的数据变得更快。
我说的硬件整合是指，以某种方式编写的代码，使得能够自然地受益于底层硬件的工作原理。有些开发者称之为mechanical sympathy。 我更倾向于硬件整合这个术语，因为计算机只有很少的机械部件，并且能够隐喻“更好的匹配（match better）”，相比“同情（sympathy）”这个词在上下文中的意思，我觉得“conform”这个词表达的非常好。当然了，这里有点吹毛求疵 了，用自己喜欢的术语就行。
4)合理的作业顺序
基于流水线并发模型实现的并发系统，在某种程度上是有可能保证作业的顺序的。作业的有序性使得它更容易地推出系统在某个特定时间点的状态。更进一 步，你可以将所有到达的作业写入到日志中去。一旦这个系统的某一部分挂掉了，该日志就可以用来重头开始重建系统当时的状态。按照特定的顺序将作业写入日 志，并按这个顺序作为有保障的作业顺序。下图展示了一种可能的设计：
实现一个有保障的作业顺序是不容易的，但往往是可行的。如果可以，它将大大简化一些任务，例如备份、数据恢复、数据复制等，这些都可以通过日志文件来完成。
流水线模型的缺点
流水线并发模型最大的缺点是作业的执行往往分布到多个工作者上，并因此分布到项目中的多个类上。这样导致在追踪某个作业到底被什么代码执行时变得困难。
同样，这也加大了代码编写的难度。有时会将工作者的代码写成回调处理的形式。若在代码中嵌入过多的回调处理，往往会出现所谓的回调地狱 （callback hell）现象。所谓回调地狱，就是意味着在追踪代码在回调过程中到底做了什么，以及确保每个回调只访问它需要的数据的时候，变得非常困难
使用并行工作者模型可以简化这个问题。你可以打开工作者的代码，从头到尾优美的阅读被执行的代码。当然并行工作者模式的代码也可能同样分布在不同的类中，但往往也能够很容易的从代码中分析执行的顺序。
同步代码块
实例同步方法
public synchronized void add(int value){
this.count += value;
}
静态同步方法
public static synchronized void add( int value ){
count += value ;
}
实例方法中的同步块
public void add(int value){
synchronized(this){
this.count += value;
}
}
静态方法中的同步块
public class MyClass {
public static synchronized void log1(String msg1, String msg2){
log.writeln(msg1);
log.writeln(msg2);
}
public static void log2(String msg1, String msg2){
synchronized(MyClass.class){
log.writeln(msg1);
log.writeln(msg2);
}
}
}
Java类锁、对象锁、私有锁、隐式锁
类锁：在代码中的方法上加了static和synchronized的锁，或者synchronized(xxx.class）的代码段，如下文中的increament()；
对象锁：在代码中的方法上加了synchronized的锁，或者synchronized(this）的代码段，如下文中的synOnMethod()和synInMethod()；
私有锁：在类内部声明一个私有属性如private Object lock，在需要加锁的代码段synchronized(lock），如下文中的synMethodWithObj()。
public class LockTestClass {
//用于类锁计数
private static int i = 0;
//私有锁
private Object object = new Object();
/**
* <p>
* 无锁方法
*
* @param threadID
* @param thread
*/
public void noSynMethod(long threadID, ObjThread thread) {
System.out.println("nosyn: class obj is " + thread + ", threadId is"
+ threadID);
}
/**
* 对象锁方法1
*/
public synchronized void synOnMethod() {
System.out.println("synOnMethod begins" + ", time = "
+ System.currentTimeMillis() + "ms");
try {
Thread.sleep(2000L);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("synOnMethod ends");
}
/**
* 对象锁方法2,采用synchronized (this)来加锁
*/
public void synInMethod() {
synchronized (this) {
System.out.println("synInMethod begins" + ", time = "
+ System.currentTimeMillis() + "ms");
try {
Thread.sleep(2000L);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("synInMethod ends");
}
}
/**
* 对象锁方法3
*/
public void synMethodWithObj() {
synchronized (object) {
System.out.println("synMethodWithObj begins" + ", time = "
+ System.currentTimeMillis() + "ms");
try {
Thread.sleep(2000L);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("synMethodWithObj ends");
}
}
/**
* 类锁
*/
public static synchronized void increament() {
System.out.println("class synchronized. i = " + i + ", time = "
+ System.currentTimeMillis() + "ms");
i++;
try {
Thread.sleep(2000L);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("class synchronized ends.");
}
}
