Java多线程积累.doc

一、多线程并发访问解决方案synchronized关键字主要解决多线程共享数据同步问题。 ThreadLocal使用场合主要解决多线程中数据因并发产生不一致问题。 ThreadLocal和Synchonized都用于解决多线程并发访问。但是ThreadLocal与synchronized有本质的区别。synchronized是利用锁的机制，使变量或代码块在某一时该只能被一个线程访问。而ThreadLocal为每一个线程都提供了变量的副本，使得每个线程在某一时间访问到的并不是同一个对象，这样就隔离了多个线程对数据的数据共享。而Synchronized却正好相反，它用于在多个线程间通信时能够获得数据共享。 Synchronized用于线程间的数据共享，而ThreadLocal则用于线程间的数据隔离。 当然ThreadLocal并不能替代synchronized,它们处理不同的问题域。Synchronized用于实现同步机制，比ThreadLocal更加复杂。 ljava中synchronized用法 使用了synchronized关键字可以轻松地解决多线程共享数据同步问题。 synchronized关键字可以作为函数的修饰符，也可作为函数内的语句，也就是平时说的同步方法和同步语句块。如果再细的分类，synchronized可作用于instance变量、object reference（对象引用）、static函数和class literals(类名称字面常量)身上。 synchronized取得的锁都是对象；每个对象只有一个锁（lock）与之相关联；实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。 synchronized的4种用法 1. 方法声明时使用,线程获得的是成员锁. 2. 对某一代码块使用,synchronized后跟括号,括号里是变量,线程获得的是成员锁. 3synchronized后面括号里是一对象,此时,线程获得的是对象锁. 4synchronized后面括号里是类,此时,线程获得的是对象锁. l java.lang.ThreadLocal()的用法 一、概述 ThreadLocal是什么呢?其实ThreadLocal并非是一个线程的本地实现版本，它并不是一个Thread，而是threadlocalvariable(线程局部变量)。也许把它命名为ThreadLocalVar更加合适。线程局部变量(ThreadLocal)其实的功用非常简单，就是为每一个使用该变量的线程都提供一个变量值的副本，是Java中一种较为特殊的线程绑定机制，是每一个线程都可以独立地改变自己的副本，而不会和其它线程的副本冲突。 ThreadLocal是如何做到为每一个线程维护变量的副本的呢?其实实现的思路很简单，在ThreadLocal类中有一个Map，用于存储每一个线程的变量的副本。 概括起来说，对于多线程资源共享的问题，同步机制采用了“以时间换空间”的方式，而ThreadLocal采用了“以空间换时间”的方式。前者仅提供一份变量，让不同的线程排队访问，而后者为每一个线程都提供了一份变量，因此可以同时访问而互不影响。 二、API说明 ThreadLocal() 创建一个线程本地变量。 T get() 返回此线程局部变量的当前线程副本中的值，如果这是线程第一次调用该方法，则创建并初始化此副本。 protected T initialValue() 返回此线程局部变量的当前线程的初始值。最多在每次访问线程来获得每个线程局部变量时调用此方法一次，即线程第一次使用 get() 方法访问变量的时候。如果线程先于 get 方法调用 set(T) 方法，则不会在线程中再调用 initialValue 方法。 若该实现只返回 null;如果程序员希望将线程局部变量初始化为 null 以外的某个值，则必须为 ThreadLocal 创建子类，并重写此方法。通常，将使用匿名内部类。initialValue 的典型实现将调用一个适当的构造方法，并返回新构造的对象。 void remove() 移除此线程局部变量的值。这可能有助于减少线程局部变量的存储需求。如果再次访问此线程局部变量，那么在默认情况下它将拥有其 initialValue。 void set(T value) 将此线程局部变量的当前线程副本中的值设置为指定值。许多应用程序不需要这项功能，它们只依赖于 initialValue() 方法来设置线程局部变量的值。 在程序中一般都重写initialValue方法，以给定一个特定的初始值。 三、典型实例 四、总结 ThreadLocal使用场合主要解决多线程中数据因并发产生不一致问题。 ThreadLocal为每个线程的中并发访问的数据提供一个副本，通过访问副本来运行业务，这样的结果是耗费了内存，单大大减少了线程同步所带来性能消耗，也减少了线程并发控制的复杂度。 ThreadLocal不能使用原子类型，只能使用Object类型。ThreadLocal的使用比synchronized要简单得多。 五、ThreadLocal使用的一般步骤 1、在多线程的类(如ThreadDemo类)中，创建一个ThreadLocal对象threadXxx，用来保存线程间需要隔离处理的对象xxx。 2、在ThreadDemo类中，创建一个获取要隔离访问的数据的方法getXxx()，在方法中判断，若ThreadLocal对象为null时候，应该new()一个隔离访问类型的对象，并强制转换为要应用的类型。 3、在ThreadDemo类的run()方法中，通过getXxx()方法获取要操作的数据，这样可以保证每个线程对应一个数据对象，在任何时刻都操作的是这个对象。二、实现 Java 多线程并发控制框架Java 提供了语言级别的线程支持，所以在 Java 中使用多线程相对于 C，C+ 来说更简单便捷，但本文并不是介绍如何在 Java 中使用多线程来来解决诸如 Web services, Number crunching 或者 I/O processing 之类的问题。在本文中，我们将讨论如何实现一个 Java 多线程的运行框架以及我们是如何来控制线程的并发同步以及顺序执行的。1、所面临的问题图 1. 线程场景这幅图中节点代表一个 single Thread，边代表执行的步骤。整幅图代表的意思是，ROOT 线程执行完毕后执行 T1 线程，T1 执行完毕后并发的执行 T2 和 T3。而从 T2 和 T3 指向 T4 的两条边表示的是 T4 必须等 T2 和 T3 都执行完毕以后才能开始执行。剩下的步骤以此类推，直到 END 作为整个过程的结束。当然，这只是个简略的示意图，可能面对的一个线程场景会有上百个线程。还有，你可以观察到这整个场景只有一个入口点和一个出口点，这意味着什么?在下文中为你解释。这其中涉及到了 Java 线程的同步互斥机制。例如如何让 T1 在 T2 和 T3 之前运行，如何让 T2 和 T3 都执行完毕之后开启 T4 线程。2、模型的描述如何来描述图 1 中所示的场景呢?可以采用 XML 的格式来描述我们的模型。我定义一个“Thread” element 来表示线程。其中 ID 是线程的唯一标识符，PRETHREAD 便是该线程的直接先决线程的ID，每个线程 ID 之间用逗号隔开。在 Thread 这个 element 里面可以加入你想要该线程执行任务的具体信息。实际上模型的描述是解决问题非常重要的一个环节，整个线程场景可以用一种一致的形式来描述，作为 Java 多线程并发控制框架引擎的输入。也就是将线程运行的模式用 XML 来描述出来，这样只用改动 XML 配置文件就可以更改整个线程运行的模式，不用改动任何的源代码。3、两种实现机制对于 Java 多线程的运行框架来说，我们将采用“外”和“内”的两种模式来实现。“外” - 主线程轮询图 2. 静态类图Thread 是工作线程。ThreadEntry 是 Thread 的包装类，prerequisite 是一个 HashMap，它含有 Thread 的先决线程的状态。如图1中显示的那样，T4 的先决线程是 T2 和 T3，那么 prerequisite 中就包含 T2 和 T3 的状态。TestScenario 中的 threadEntryList 中包含所有的 ThreadEntry。图 3. 线程执行场景TestScenario 作为主线程，作为一个“外”在的监控者，不断地轮询 threadEntryList 中所有 ThreadEntry 的状态，当 ThreadEntry 接受到 isReady 的查询后查询自己的 prerequisite，当其中所有的先决线程的状态为“正常结束时”，它便返回 ready，那么 TestScenario 便会调用 ThreadEntry 的 startThread() 方法授权该 ThreadEntry 运行线程，Thread 便通过 run() 方法来真正执行线程。并在正常执行完毕后调用 setPreRequisteState() 方法来更新整个 Scenario，threadEntryList 中所有 ThreadEntry 中 prerequisite 里面含有该 Thread 的状态信息为“正常结束”。图 4. 状态更改的过程如图 1 中所示的 T4 的先决线程为 T2 和 T3，T2 和 T3 并行执行。如图 4 所示，假设 T2 先执行完毕，它会调用 setPreRequisteState() 方法来更新整个 Scenario， threadEntryList 中所有 ThreadEntry 中 prerequisite 里面含有该 T2 的状态信息为“正常结束”。此时，T4 的 prerequisite 中 T2 的状态为“正常结束”，但是 T3 还没有执行完毕，所以其状态为“未完毕”。所以 T4 的 isReady 查询返回为 false，T4 不会执行。只有当 T3 执行完毕后更新状态为“正常结束”后，T4 的状态才为 ready，T4 才会开始运行。其余的节点也以此类推，它们正常执行完毕的时候会在整个的 scenario 中广播该线程正常结束的信息，由主线程不断地轮询各个 ThreadEntry 的状态来开启各个线程。这便是采用主控线程轮询状态表的方式来控制 Java 多线程运行框架的实现方式之一。优点：概念结构清晰明了，实现简单。避免采用 Java 的锁机制，减少产生死锁的几率。当发生异常导致其中某些线程不能正常执行完毕的时候，不会产生挂起的线程。缺点：采用主线程轮询机制，耗费 CPU 时间。当图中的节点太多的(n? 而线程单个线程执行时间比较短的时候 t4、“内” - waitify相对于“外”-主线程轮询机制来说，“内”采用的是自我控制连锁触发机制。图 5. 锁机制的静态类图Thread 中的 lock 为当前 Thread 的 lock，lockList 是一个 HashMap，持有其后继线程的 lock 的引用，getLock 和 setLock 可以对 lockList 中的 Lock 进行操作。其中很重要的一个成员是 waitForCount，这是一个引用计数。表明当前线程正在等待的先决线程的个数，例如图 1 中所示的 T4，在初始的情况下，他等待的先决线程是 T2 和 T3，那么它的 waitForCount 等于 2。图 6. 锁机制执行顺序图当整个过程开始运行的时候，我们将所有的线程 start，但是每个线程所持的 lock 都处于 wait 状态，线程都会处于 waiting 的状态。此时，我们将 root thread 所持有的自身的 lock notify，这样 root thread 就会运行起来。当 root 的 run 方法执行完毕以后。它会检查其后续线程的 waitForCount，并将其值减一。然后再次检查 waitForCount，如果 waitForCount 等于 0，表示该后续线程的所有先决线程都已经执行完毕，此时我们 notify 该线程的 lock，该后续线程便可以从 waiting 的状态转换成为 running 的状态。然后这个过程连锁递归的进行下去，整个过程便会执行完毕。我们还是以 T2，T3，T4 为例，当进行 initThreadLock 过程的时候，我们可以知道 T4 有两个直接先决线程 T2 和 T3，所以 T4 的 waitForCount 等于 2。我们假设 T3 先执行完毕，T2 仍然在 running 的状态，此时他会首先遍历其所有的直接后继线程，并将他们的 waitForCount 减去 1，此时他只有一个直接后继线程 T4，于是 T4 的 waitForCount 减去 1 以后值变为 1，不等于 0，此时不会将 T4 的 lock notify，T4 继续 waiting。当 T2 执行完毕之后，他会执行与 T3 相同的步骤，此时 T4 的 waitForCount 等于 0，T2 便 notify T4 的 lock，于是 T4 从 waiting 状态转换成为 running 状态。其他的节点也是相似的情况。当然，我们也可以将整个过程的信息放在另外的一个全局对象中，所有的线程都去查找该全局对象来获取各自所需的信息，而不是采取这种分布式存储的方式。优点：采用 waitify 机制而不采用轮询的机制，不会浪费CPU资源。执行效率较高。而且相对于“外”-主线程轮询的机制来说实时性更好。缺点：采用 Java 线程 Object 的锁机制，实现起来较为复杂。而且采取一种连锁触发的方式，如果其中某些线程异常，会导致所有其后继线程的挂起而造成整个 scenario 的运行失败。为了防止这种情况的发生，我们还必须建立一套线程监控的机制