concurrent

2.0时代的软件空前地活跃在人类生活的方方面面，从而带来了更多的计算量。因此2.0不可避免地对计算提出了新的需求、引发了新的思考，在这其中，多核带来的并行计算和并发编程无疑是最为深刻的一点。 我们都能依稀记得，在2005年Sun发布了代号为Tiger的Java 5。在其众多的特性之中， JVM的改进和java.util.concurrent包的出现无疑非常引人注目。改进后的JVM可以使用低层机器指令取代锁，精化了互斥访问的粒度，提高了系统的可伸缩性和活性。而concurrent包提供了大量线程和锁之上的并发抽象，比如线程池、闭锁、信号量、关卡等。这些可以帮助开发者快速地构建出高效、可伸缩的系统来。就在同一年，还发生了另一件影响深远的事件：AMD首次发布了其双核CPU，从而打响了AMD与Intel两大芯片厂商的多核之争。 当Java遇到多核 早在十多年前，IBM、Sun与HP就已经设计出了双核处理器，比如IBM于2001年推出的基于双核的POWER4处理器和Sun的UltraSPARC芯片，但这些双核处理器都是用于高端的RISC领域，价格高昂，被大众使用的X86并没有享受到它带来的性能优势。直到Intel和AMD相继推出自己的双核处理器后，X86领域才算是有了自己的多核架构。 所谓双核处理器，简单地说就是在一块CPU基板上集成两个处理器核心，并通过并行总线将各处理器核心连接起来

从JDK 1.5之后，在java.util.concurrent包下引入了好多的处理多线程的工具类，本文将介绍用来控制资源同时访问个数的Semaphore工具类, 然后采用Semaphore给出一个泊车的实例,最后给出 Semaphore 和 CountDownLatch 的几点比较。 Semaphore工具类介绍 Semaphore类描述 /** * A counting semaphore. Conceptually, a semaphore maintains a set of * permits. Each {@link #acquire} blocks if necessary until a permit is * available, and then takes it. Each {@link #release} adds a permit, * potentially releasing a blocking acquirer. * However, no actual permit objects are used; the <tt>Semaphore</tt> just * keeps a count of the number available and acts accordingly. * * <p>Semaphores are often used

其实这一节要说的重点又是 synchronized ，因为和内置锁最相关的应该就是 synchronized 了。当然我们还是会从一些例子开始讲起。样例程序还是来自那本书： @NotThreadSafe public class UnsafeCachingFactorizer implements Servlet { private final AtomicReference<BigInteger> lastNumber = new AtomicReference<BigInteger>(); private final AtomicReference<BigInteger[]> lastFactors = new AtomicReference<BigInteger[]>(); public void service(ServletRequest req, ServletResponse resp) { BigInteger i = extractFromRequest(req); if (i.equals(lastNumber.get())) encodeIntoResponse(resp, lastFactors.get() ); else { BigInteger[] factors = factor(i); lastNumber.set(i); lastFactors

Java中的并发包，是在Java代码中并发程序的热门话题。如果我们去读concurrent包的源码时，会发现其真正的核心是 AbstractQueuedSynchronizer ， 简称 AQS 框架 , 而 Doug Lea 大神正是此包的作者。 之前也看过一遍 AbstractQueuedSynchronize，但印象不深，只有依稀的印象。这次重新学习一遍，并整理出笔记，希望对自己或者是别人有用。当然了，笔者也是浅显的过一遍，很多细节也并不是完全理解。 建议读者先看这个系列的文章：Inside AbstractQueuedSynchronizer，之后再继续本篇。 首先，AQS会对进行 acquire 而被阻塞的线程进行管理，说是管理，其实就是内部维护了一个FIFO队列，这个队列是一个双向链表。链头可以理解为是一个空的节点，除了链头以外，每个节点内部都持有着一个线程，同时，有着两个重要的字段：waitStatus 和 nextWaiter。nextWaiter一般是作用与在使用Condition时的队列。而waitStatus则有以下几个字段： SIGNAL 表示下一个节点应该被唤醒。为什么是下一个节点？因为刚刚说了，这个FIFO队列，链头都是一个空的节点，但此节点的 waitStatus 正好就表示了要对下一节点做的事情 CANCELLED 表示此节点持有的线程被中断

前两篇文章已经对Fork Join的设计和JDK中源码的简要分析。这篇文章，我们来简单地看看我们在开发中怎么对JDK提供的工具类进行应用，以提高我们的需求处理效率。 Fork Join这东西确实用好了能给我们的任务处理提高效率，也为开发带来方便。但Fork Join不是那么容易用好的，我们先来看几个例子（反例）。 ####1. 反例错误分析 我们先来看看这篇文章中提供的例子： http://www.iteye.com/topic/643724 （因为是反例，就不提供超链接了，只以普通文本给出URL） 这篇文章是我学习和整理Fork Join时搜索到的一篇文章，其实总的来说这篇文章前面分析得还是比较好的，只是给出的第一个例子（有返回结果的RecursiveTask应用的例子）没有正确地对Fork Join进行应用。为了方便分析，还是贴下这个例子中具体的的代码吧。 public class Calculator extends RecursiveTask { private static final int THRESHOLD = 100; private int start; private int end; public Calculator(int start, int end) { this.start = start; this.end = end; } @Override