你是我的天晴

BlockingQueue接口定义了一种阻塞的FIFO queue，每一个BlockingQueue都有一个容量，让容量满时往BlockingQueue中添加数据时会造成阻塞，当容量为空时取元素操作会阻塞。 ArrayBlockingQueue是一个由数组支持的有界阻塞队列。在读写操作上都需要锁住整个容器，因此吞吐量与一般的实现是相似的，适合于实现“生产者消费者”模式。 基于链表的

昨天知道了findbugs这个工具 而且用这个工具找到了潜在几个问题，有一个是便利map用的keyset  findbugs建议改成entrtyset，还有一个就是 SimpleDateFormat不是线程安全的：As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. The detecto

在Java中java.lang.Thread类有一个变量threadStatus，标示了该线程的当前状态，它是一个int类型，但是对应的get方法返回值是一个枚举（Thread的内部类），源码如下：public enum State { /** * Thread state for a thread which has not yet started.

很多编码者都会说，Lock类和synchronized关键字用在代码块的并发性和内存上时语义 是一样的，都是保持代码块同时只有一个线程具有执行权。这样的说法只对了一半，我们以一个任务提交给多个线程运行为例，来看看使用显式锁（Lock类）和内部锁（synchronized 关键字）有什么不同。首先定义一个任务：class Task{ public void doSomething(){ t

多线程应用有两种实现方式，一种是实现Runnable接口，另一种是继承Thread类，这 两个方式都有缺点：run方法没有返回值，不能抛出异常（这两个缺点归根到底是Runable 接口的缺陷，Thread也是实现了 Runnable接口），如果需要知道一个线程的运行结果就需要用 户自行设计，线程类自身也不能提供返回值和异常。但是从Java 1.5开始引入了一个新的接口 Callable,它类似于R

我们要编写一个Socket应用，监听指定端口，实现数据包的接收和发送逻辑，这在早期系统间进行数据交互是经常使用的，这类接口通常需要考虑两个问题：一是避免线程阻塞， 保证接收的数据尽快处理；二是接口的稳定性和可靠性问题，数据包很复杂，接口服务的系统也很多，一旦守候线程出现异常就会导致Socket停止响应，这是非常危险的，那我们有什 么办法来避免吗？Java 1.5版本以后在Thread类中增加了

线程的优先级（Priority)决定了线程获得CPU运行的机会，优先级越髙获得的运行机 会越大，优先级越低获得的机会越小。Java的线程有10个级别（准确地说是11个级别，级 别为〇的线程是JVM的，应用程序不能设置该级别），那是不是说级别是10的线程肯定比 级别为9的线程先运行呢？我们来看如下一个多线程类：public class TestPriorityThread implements

线程启动完毕后，在运行时可能需要终止，Java提供的终止方法只有一个stop，但是我 不建议使用这个方法，因为它有以下三个问题：(1)  stop方法是过时的从Java编码规则来说，已经过时的方法不建议采用。(2)  stop方法会导致代码逻辑不完整stop方法是一种“恶意”的中断，一旦执行stop方法，即终止当前正在运行的线程，不 管线程逻辑是否完整，这是非常危险的。看如下的代码

多线程比较简单的实现方式是继承Thread类，然后覆写run方法，在客户端程序中通过 调用对象的start方法即可启动一个线程，这是多线程程序的标准写法。不知道读者是否还能回想起自己的第一个多线程demo呢？估计一般是这样写的：class MultiThread extends Thread{ @Override public void start(){ //调用线在体