久久亚洲一区,blacked蜜桃精品一区,国产自产自拍视频在线观看

Java�q�发基础实践--死锁(�?

Sha Jiang — Sun, 29 Dec 2013 12:19:00 GMT

Java�q�发基础实践--死锁

本文�?a href="http://www.aygfsteel.com/jiangshachina/category/53896.html">Java�q�发基础实践�p�d��中的一��，介绍了最��单的死锁场景�Q��ƈ使用jstack产生的thread dump来查找死锁�?2013.12.29最后更�?

1. 死锁
��Z��能够�l�护�U�程的安全性，Java提供的锁机制�Q�但不恰当地使用锁则可能产生死锁。死锁是�q�发�~�程中一个无法绕开的问题。只要在一个�Q务中使用了一个以上的锁，那么��存在死锁的风险�?br />死锁产生的直接原因非常简单，即两个线�E�在�怺��{�待�Ҏ��所执有的锁�?br />
2. 锁顺序死�?/span>
在死锁场景中�Q�最典型的就是锁��序死锁�Q�代码清�?��是一个很常见的示例�?br />

清单1
public class DeadLock {

    private Object leftLock = new Object();
    private Object rightLock = new Object();

    public void leftRight() {
        synchronized (leftLock) {
            try {
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }

            synchronized (rightLock) {
                System.out.println("leftRight");
            }
        }
    }

    public void rightLeft() {
        synchronized (rightLock) {
            try {
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }

            synchronized (leftLock) {
                System.out.println("leftRight");
            }
        }
    }

    public static void main(String[] args) {
        final DeadLock deadLock = new DeadLock();

        Thread t1 = new Thread(new Runnable() {

            @Override
            public void run() {
                deadLock.leftRight();
            }
        });

        Thread t2 = new Thread(new Runnable() {

            @Override
            public void run() {
                deadLock.rightLeft();
            }
        });

        t1.start();
        t2.start();
    }
}

3. Thread Dump
JDK提供了一�l�命令行工具�Q�其中就包括jstack。通过jstack可以获取当前正运行的Java�q�程的java stack和native stack信息。如果Java�q�程崩溃了，也可以通过它来获取core file中的java stack和native stack信息�Q�以方便我们定位问题�?br />��Z��能够使用jstack去输出目标Java�q�程的thread dump�Q�首先必��要弄清楚在执行清单1的程序时�Q�该�E�序的进�E�号。JDK提供的另一个命令行工具jps可以获取�pȝ��中所有Java�q�程的相关信息�?br />在命令行�H�口中执行命�?em>jps�Q�即可以得到清单2所�C�的�l�果

清单2
C:\Documents and Settings\Administrator>jps
2848
4552 DeadLock
5256 Jps

其中4552��是在笔者机器上执行�E�序DeadLock时所生成Java�q�程的进�E�号�?br />然后再执行命�?em>jstack 4552�Q�在�W�者的机器上就会得到清�?所�C�的�l�果

清单3
C:\Documents and Settings\Administrator>jstack 4552
2013-12-29 18:45:41
Full thread dump Java HotSpot(TM) Client VM (23.25-b01 mixed mode, sharing):

"DestroyJavaVM" prio=6 tid=0x00878800 nid=0xd00 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Thread-1" prio=6 tid=0x02b56c00 nid=0x14ec waiting for monitor entry [0x02fdf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at concurrency.deadlock.DeadLock.rightLeft(DeadLock.java:33)
        - waiting to lock <0x22be6598> (a java.lang.Object)
        - locked <0x22be65a0> (a java.lang.Object)
        at concurrency.deadlock.DeadLock$2.run(DeadLock.java:53)
        at java.lang.Thread.run(Thread.java:724)

"Thread-0" prio=6 tid=0x02b55c00 nid=0x354 waiting for monitor entry [0x02f8f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at concurrency.deadlock.DeadLock.leftRight(DeadLock.java:19)
        - waiting to lock <0x22be65a0> (a java.lang.Object)
        - locked <0x22be6598> (a java.lang.Object)
        at concurrency.deadlock.DeadLock$1.run(DeadLock.java:45)
        at java.lang.Thread.run(Thread.java:724)

"Service Thread" daemon prio=6 tid=0x02b34800 nid=0x133c runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread0" daemon prio=10 tid=0x02b13800 nid=0x10fc waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Attach Listener" daemon prio=10 tid=0x02b11c00 nid=0x1424 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x02b10800 nid=0x1100 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=8 tid=0x02af4c00 nid=0x1238 in Object.wait() [0x02daf000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22b60fb8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
        - locked <0x22b60fb8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)

"Reference Handler" daemon prio=10 tid=0x02af0000 nid=0x12e8 in Object.wait() [0x02d5f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22b60da0> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:503)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
        - locked <0x22b60da0> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x02aee400 nid=0x129c runnable

"VM Periodic Task Thread" prio=10 tid=0x02b48000 nid=0x89c waiting on condition

JNI global references: 117

Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x02af4a3c (object 0x22be6598, a java.lang.Object),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x02af310c (object 0x22be65a0, a java.lang.Object),
  which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1":
        at concurrency.deadlock.DeadLock.rightLeft(DeadLock.java:33)
        - waiting to lock <0x22be6598> (a java.lang.Object)
        - locked <0x22be65a0> (a java.lang.Object)
        at concurrency.deadlock.DeadLock$2.run(DeadLock.java:53)
        at java.lang.Thread.run(Thread.java:724)
"Thread-0":
        at concurrency.deadlock.DeadLock.leftRight(DeadLock.java:19)
        - waiting to lock <0x22be65a0> (a java.lang.Object)
        - locked <0x22be6598> (a java.lang.Object)
        at concurrency.deadlock.DeadLock$1.run(DeadLock.java:45)
        at java.lang.Thread.run(Thread.java:724)

Found 1 deadlock.

在上�q�输��Z��Q�我们可以很明确地看��C��个死�?br />

"Thread-1":
  waiting to lock monitor 0x02af4a3c (object 0x22be6598, a java.lang.Object),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x02af310c (object 0x22be65a0, a java.lang.Object),
  which is held by "Thread-1"

�q�且它还标明了程序是在哪个地�Ҏ��发现了上�q�死�?br />

"Thread-1":
        at concurrency.deadlock.DeadLock.rightLeft(DeadLock.java:33)
        - waiting to lock <0x22be6598> (a java.lang.Object)
        - locked <0x22be65a0> (a java.lang.Object)
        at concurrency.deadlock.DeadLock$2.run(DeadLock.java:53)
        at java.lang.Thread.run(Thread.java:724)
"Thread-0":
        at concurrency.deadlock.DeadLock.leftRight(DeadLock.java:19)
        - waiting to lock <0x22be65a0> (a java.lang.Object)
        - locked <0x22be6598> (a java.lang.Object)
        at concurrency.deadlock.DeadLock$1.run(DeadLock.java:45)
        at java.lang.Thread.run(Thread.java:724)

4. ��结
死锁产生的直接原因非常简单，即两个线�E�在�怺��{�待�Ҏ��所执有的锁。锁��序死锁是其中最�l�典的场景，此外�q�有动态的锁顺序死锁。虽然表现�Ş式有所不同�Q�但本质上都是两个线�E�在以不同的��序来获取相同锁�Ӟ��发生了死锁问题�?br />使用thread dump可以帮助我们分析死锁产生的原因。除了直接��用jstack命��o来获取thread dump输出以外�Q�JDK�q�提供了jvisualvm工具�Q�它能以可视化的方式展示Java�E�序的进�E�号�q�导出thread dump�?/div>

Sha Jiang 2013-12-29 20:19 发表评论

Java�q�发基础实践--分而治�?�?

Sha Jiang — Wed, 23 Oct 2013 15:27:00 GMT

摘要: Java�q�发基础实践--分而治之本�p�d��的第三篇文章��以实现一个极��单的查找最大数的�Q务�ؓ例，分别�l�出了四个版本：1.��序执行�Q?.��Z��传统的Thread.join()�Q?.��Z��q�发工具包的Future�Q?.��Z��JDK 7引入的Fork/Join框架�?2013.10.25最后更�? 分而治�?Divide-and-Conquer)是解军_��杂问题的常用�Ҏ��。在�q�发... 阅读全文

Sha Jiang 2013-10-23 23:27 发表评论

Java�q�发基础实践--退��Z�Q务II(�?

Sha Jiang — Mon, 07 Oct 2013 08:55:00 GMT

Java�q�发基础实践--退��Z�Q务II

�?a href="http://www.aygfsteel.com/jiangshachina/category/53896.html">本系�?/a>�?a href="http://www.aygfsteel.com/jiangshachina/archive/2013/09/21/404269.html">上一��?/a>中所�q�的退出�ƈ发�Q务的方式都是��Z��JDK 5之前的API�Q�本文将介绍使用由JDK 5引入的�ƈ发工具包中的API来退��Z�Q务�?2013.10.08最后更�?

在本�p�d��的前一��中讲述了三�U�退出�ƈ发�Q务的方式--停止�U�程�Q�可取消的�Q务；中断�Q�但都是��Z��JDK 5之前的API。本��将介绍由JDK 5引入的java.concurrent包中的Future来取消�Q务的执行�?br />
1. Future模式
Future是�ƈ发编�E�中的一�U�常见设计模式，它相当于是Proxy模式与Thread-Per-Message模式的结合。即�Q�每�ơ都创徏一个单独的�U�程��L��行一个耗时的�Q务，�q�且创徏一个Future对象��L��有实际的��d��对象�Q�在��来需要的时候再去获取实际�Q务的执行�l�果�?br />依然先创��Z��个用于扫描文件的��d��FileScannerTask�Q�如代码清单1所�C�，

清单1
public class FileScannerTask implements Runnable {

    private File root = null;

    private ArrayList<String> filePaths = new ArrayList<String>();

    public FileScannerTask(File root) {
        if (root == null || !root.exists() || !root.isDirectory()) {
            throw new IllegalArgumentException("root must be directory");
        }

        this.root = root;
    }

    @Override
    public void run() {
        travleFiles(root);
    }

    private void travleFiles(File parent) {
        String filePath = parent.getAbsolutePath();
        filePaths.add(filePath);

        if (parent.isDirectory()) {
            File[] children = parent.listFiles();
            if (children != null) {
                for (File child : children) {
                    travleFiles(child);
                }
            }
        }
    }

    public List<String> getFilePaths() {
        return (List<String>) filePaths.clone();
    }
}

此处的文件扫描�Q务，提供了一个getFilePaths()�Ҏ��以允讔R��旉��可以取出当前已扫描过的文件的路径(相当于一个�Q务快�?。然后，创徏一个针对该��d��的Future�c�，如代码清�?所�C�，

清单2
public class FileScannerFuture {

    private FileScannerTask task = null;

    public FileScannerFuture(FileScannerTask task) {
        new Thread(task).start();
        this.task = task;
    }

    public List<String> getResult() {
        return task.getFilePaths();
    }
}

FileScannerFuture持有FileScannerTask的引用，�q�创��Z��个独立的�U�程来执行该��d��。在��d��的执行过�E�中�Q�应用程序可以在"未来"的某个时��d��获取一个�Q务的快照�Q�如代码清单3所�C�，

清单3
public static void main(String[] args) throws Exception {
    FileScannerFuture future = new FileScannerFuture(new FileScannerTask(new File("C:")));

    TimeUnit.SECONDS.sleep(1);
    List<String> filePaths1 = future.getResult();
    System.out.println(filePaths1.size());

    TimeUnit.SECONDS.sleep(1);
    List<String> filePaths2 = future.getResult();
    System.out.println(filePaths2.size());
}

2. 使用�q�发工具包中的Future实现
前面所展示的Future实现十分的简陋，没有实际应用的意义。��用FileScannerFuture�Q�应用程序在获取filePaths�Ӟ��无法得知其获取的是否为最�l�结果，��x��法判断FileScannerTask是否已经完成。而且�Q�也不能在必要时停止FileScannerTask的执行。毫无疑问，由JDK 5引入的�ƈ发工具包肯定会提供此�c�d��用工��P��如FutureTask。�ؓ了��用�ƈ发工具包中的Future�Q�需要修改前�q�的FileScannerTask实现�Q�让其实现Callable接口�Q�如代码清单4所�C�，

清单4
public class FileScannerTask implements Callable<List<String>> {

    private File root = null;

    private List<String> filePaths = new ArrayList<String>();

    public FileScannerTask(File root) {
        if (root == null || !root.exists() || !root.isDirectory()) {
            throw new IllegalArgumentException("root must be directory");
        }

        this.root = root;
    }

    @Override
    public List<String> call() {
        travleFiles(root);
        return filePaths;
    }

    private void travleFiles(File parent) {
        String filePath = parent.getAbsolutePath();
        filePaths.add(filePath);

        if (parent.isDirectory()) {
            File[] children = parent.listFiles();
            if (children != null) {
                for (File child : children) {
                    travleFiles(child);
                }
            }
        }
    }

    public List<String> getFilePaths() {
        return (List<String>) filePaths.clone();
    }
}

应用�E�序也要相应的修�Ҏ��如代码清�?所�C�，使用ExecutorService来提交�Q务，�q�创��Z��个Future/FutureTask实例�?br />

清单5
public static void main(String[] args) {
    ExecutorService executorService = Executors.newCachedThreadPool();
    Future<List<String>> future = executorService.submit(new FileScannerTask(new File("C:")));

    try {
        List<String> filePaths = future.get();
        System.out.println(filePaths.size());
    } catch (InterruptedException e) {
        e.printStackTrace();
    } catch (ExecutionException e) {
        e.printStackTrace();
    }

    executorService.shutdown();
}

此处��是调用Future.get()�Ҏ��来获取�Q务的执行�l�果�Q�如果�Q务没有执行完毕，那么该方法将会被��d��。该Future实现的好处就是，正常情况下，只有在�Q务执行完毕之后才能获取其�l�果�Q�以保证该结果是最�l�执行结果�?br />
3. 使用Future取消��d��
Future除了定义有可获取执行�l�果的get�Ҏ��(get()以及get(long timeout, TimeUnit unit))�Q�还定义了三个方法：cancel()�Q�isCancelled()以及isDone()�Q�用于取消�Q务，以及判定��d��是否已被取消、已执行完毕。如代码清单6所�C�，

清单6
public interface Future<V> {

    boolean cancel(boolean mayInterruptIfRunning);
    boolean isCancelled();
    boolean isDone();

}

其中�Q�cancel()�Ҏ��中的boolean参数若�ؓtrue�Q�表�C�在取消该�Q务时�Q�若执行该�Q务的�U�程仍在�q�行中，则对其进行中断。如代码清单7所�C�，若�Q务执行超时了�Q�那么就取消它�?br />

清单7
public static void main(String[] args) {
    ExecutorService executorService = Executors.newCachedThreadPool();
    Future<List<String>> future = executorService.submit(new FileScannerTask(new File("C:")));

    try {
        List<String> filePaths = future.get(1, TimeUnit.SECONDS);
        System.out.println(filePaths.size());
    } catch (InterruptedException e) {
        e.printStackTrace();
    } catch (ExecutionException e) {
        e.printStackTrace();
    } catch (TimeoutException e) {
        e.printStackTrace();
    } finally {
        future.cancel(true);
    }

    executorService.shutdown();
}

在实际应用中�Q�取消�Q务的原由肯定不仅仅只是超时这么简单，�q�可能是�׃��接受��C��用户的指令。此�Ӟ��则可能会从另一个独立线�E�去取消该�Q务。除了取消�Q务之外，有时�q�需要取��Z�Q务中已经生成的部分结果。但��Z��能够响应��d��的退出，首先需要修改FileScannerTask�Q��得当��d��被取�?中断)�Ӟ��d��能够真正的快速停止�ƈ�q�回�Q�如代码清单8所�C�，

清单8
public class FileScannerTask implements Callable<List<String>> {



    private void travleFiles(File parent) {
        if (Thread.currentThread().isInterrupted()) {
            return;
        }

        String filePath = parent.getAbsolutePath();
        filePaths.add(filePath);

        if (parent.isDirectory()) {
            File[] children = parent.listFiles();
            if (children != null) {
                for (File child : children) {
                    travleFiles(child);
                }
            }
        }
    }


}

相应��C��改应用程序的代码�Q�如代码清单9所�C�，

清单9
public static void main(String[] args) {
    ExecutorService executorService = Executors.newCachedThreadPool();
    FileScannerTask task = new FileScannerTask(new File("C:"));
    final Future<List<String>> future = executorService.submit(task);

    new Thread(new Runnable() {

        @Override
        public void run() {
            try {
                TimeUnit.SECONDS.sleep(1);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            future.cancel(true);
        }
    }).start();

    try {
        List<String> filePaths = future.get();
        System.out.println(filePaths.size());
    } catch (InterruptedException e) {
        e.printStackTrace();
    } catch (ExecutionException e) {
        e.printStackTrace();
    } catch (CancellationException e) {
        List<String> filePaths = task.getFilePaths();
        System.out.println("Partly result: " + filePaths.size());
    }

    executorService.shutdown();
}

�׃��可知�Q�此处��用Future.cancel(true)的本质依然是利用了线�E�的中断机制�?br />
4. ��结
使用Future可以在�Q务启动之后的特定时机再去获取��d��的执行结果。由JDK 5引入的�ƈ发工具包中提供的Future实现不仅可以获取��d��的执行结果，�q�可以用于取消�Q务的执行�?/div>

Sha Jiang 2013-10-07 16:55 发表评论

Java�q�发基础实践--退��Z�Q务I(�?

Sha Jiang — Sat, 21 Sep 2013 11:11:00 GMT

Java�q�发基础实践--退��Z�Q务I

计划写一�?Java�q�发基础实践"�p�d��Q�算作本人对Java�q�发学习与实�늚��单�ȝ��。本文是该系列的�W�一��，介绍了退出�ƈ发�Q务的最��单方法�?2013.09.25最后更�?

在一个�ƈ发�Q务被启动之后�Q�不要期望它��L��会执行完成。由于时间限�Ӟ��资源限制�Q�用��h��作，甚至是�Q务中的异�?��其是运行时异常)�Q?..都可能造成��d��不能执行完成。如何恰当地退��Z�Q务是一个很常见的问题，而且实现�Ҏ��也不一而��?/span>

1. ��d��
创徏一个�ƈ发�Q务，递归地获取指定目录下的所有子目录与文件的�l�对路径�Q�最后再��这些�\径信息保存到一个文件中�Q�如代码清单1所�C�：

清单1
public class FileScanner implements Runnable {

    private File root = null;

    private List<String> filePaths = new ArrayList<String>();

    public FileScanner1(File root) {
        if (root == null || !root.exists() || !root.isDirectory()) {
            throw new IllegalArgumentException("root must be legal directory");
        }

        this.root = root;
    }

    @Override
    public void run() {
        travleFiles(root);
        try {
            saveFilePaths();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    private void travleFiles(File parent) {
        String filePath = parent.getAbsolutePath();
        filePaths.add(filePath);

        if (parent.isDirectory()) {
            File[] children = parent.listFiles();
            for (File child : children) {
                travleFiles(child);
            }
        }
    }

    private void saveFilePaths() throws IOException {
        FileWriter fos = new FileWriter(new File(root.getAbsoluteFile()
                + File.separator + "filePaths.out"));
        for (String filePath : filePaths) {
            fos.write(filePath + "\n");
        }
        fos.close();
    }
}

2. 停止�U�程
有一个很直接�Q�也很干脆的方式来停止线�E�，��是调用Thread.stop()�Ҏ��Q�如代码清单2所�C�：

清单2
public static void main(String[] args) throws Exception {
    FileScanner task = new FileScanner(new File("C:"));
    Thread taskThread = new Thread(task);
    taskThread.start();

    TimeUnit.SECONDS.sleep(1);
    taskThread.stop();
}

但是�Q�地球�h都知道Thread.stop()在很久很久之前就不推荐��用了。根�?a >官方文档的介�l�，该方法存在着固有的不安全性。当停止�U�程�Ӟ��会释放该线�E�所占有的全部监视锁�Q�这��׃��造成受这些锁保护的对象的不一致性。在执行清单2的应用程序时�Q�它的运行结果是不确定的。它可能会输��Z��个文�Ӟ��其中包含部分的被扫描�q�的目录和文件。但它也很有可能什么也不输出，因�ؓ在执行FileWriter.write()的过�E�中�Q�可能由于线�E�停止而造成了I/O异常�Q��得最�l�无法得到输出文件�?/span>

3. 可取消的��d��
另外一�U�十分常见的途径是，在设计之初，我们��׃��d��是可被取消的。一般地�Q�就是提供一个取消标志或讑֮�一个取消条�Ӟ��一旦�Q务遇到该标志或满��了取消条�g�Q�就会结束�Q务的执行。如代码清单3所�C�：

清单3
public class FileScanner implements Runnable {

    private File root = null;

    private List<String> filePaths = new ArrayList<String>();

    private boolean cancel = false;

    public FileScanner(File root) {

    }

    @Override
    public void run() {

    }

    private void travleFiles(File parent) {
        if (cancel) {
            return;
        }

        String filePath = parent.getAbsolutePath();
        filePaths.add(filePath);

        if (parent.isDirectory()) {
            File[] children = parent.listFiles();
            for (File child : children) {
                travleFiles(child);
            }
        }
    }

    private void saveFilePaths() throws IOException {

    }

    public void cancel() {
        cancel = true;
    }
}

新的FileScanner实现提供一个cancel标志�Q�travleFiles()会遍历新的文件之前检��该标志�Q�若该标志�ؓtrue�Q�则会立卌��回。代码清�?是��用新��d��的应用程序�?/span>

清单4
public static void main(String[] args) throws Exception {
    FileScanner task = new FileScanner(new File("C:"));
    Thread taskThread = new Thread(task);
    taskThread.start();

    TimeUnit.SECONDS.sleep(3);
    task.cancel();
}

但有些时候��用可取消的�Q务，�q�不能快速地退��Z�Q务。因��Z�Q务在��取消标志之前，可能正处于等待状态，甚至可能被阻塞着。对清单2中的FileScanner�E�作修改�Q�让每次讉K��新的文�g之前先睡�?0�U�钟�Q�如代码清单5所�C�：

清单5
public class FileScanner implements Runnable {



    private void travleFiles(File parent) {
        try {
            TimeUnit.SECONDS.sleep(10);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        if (cancel) {
            return;
        }


    }

    private void saveFilePaths() throws IOException {

    }

    public void cancel() {
        cancel = true;
    }
}

再执行清�?中的应用�E�序�Ӟ��可能发现��d��q�没有很快速的退出，而是又等待了大约7�U�钟才退出。如果在��查cancel标志之前要先获取某个受锁保护的资源，那么该�Q务就会被��d��Q��ƈ且无法确定何时能够退出。对于这�U�情况，��需要��用中断了�?/span>

4. 中断
中断是一�U�协作机�Ӟ��它�ƈ不会真正地停止一个线�E�，而只是提醒线�E�需要被中断�Q��ƈ��线�E�的中断状态设�|��ؓtrue。如果线�E�正在执行一些可抛出InterruptedException的方法，如Thread.sleep()�Q�Thread.join()和Object.wait()�Q�那么当�U�程被中断时�Q�上�q�方法就会抛出InterruptedException�Q��ƈ且中断状态会被重新设�|��ؓfalse。�Q务程序只要恰当处理该异常�Q�就可以正常地退��Z�Q务。对清单5再稍作修改，卻I��如果��d��在睡眠时遇上了InterruptedException�Q�那么就取消��d��。如代码清单6所�C�：

清单6
public class FileScanner implements Runnable {



    private void travleFiles(File parent) {
        try {
            TimeUnit.SECONDS.sleep(10);
        } catch (InterruptedException e) {
            cancel();
        }

        if (cancel) {
            return;
        }


    }


}

同时��清�?中的应用�E�序�Q�此时将调用Thread.interrupt()�Ҏ��M��断线�E�，如代码清�?所�C�：

清单7
public static void main(String[] args) throws Exception {
    FileScanner3 task = new FileScanner3(new File("C:"));
    Thread taskThread = new Thread(task);
    taskThread.start();

    TimeUnit.SECONDS.sleep(3);
    taskThread.interrupt();
}

或者更�q�一步，仅��用中断状态来控制�E�序的退出，而不再��用可取消的�Q�?卻I��删除cancel标志)�Q�将清单6中的FileScanner修改成如下：

清单8
public class FileScanner implements Runnable {



    private void travleFiles(File parent) {
        try {
            TimeUnit.SECONDS.sleep(10);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }

        if (Thread.currentThread().isInterrupted()) {
            return;
        }


    }


}

再次执行清单7的应用程序后�Q�新的FileScanner也能��x��的退��Z��。值得注意的是�Q�因为当sleep()�Ҏ��抛出InterruptedException�Ӟ��该线�E�的中断状态将又会被设�|��ؓfalse�Q�所以必��要再次调用interrupt()�Ҏ��来保存中断状态，�q�样在后面才可以利用中断状态来判定是否需要返回travleFiles()�Ҏ��。当�Ӟ��对于此处的例子，在收到InterruptedException时也可以选择直接�q�回�Q�如代码清单9所�C�：

清单9
public class FileScanner implements Runnable {



    private void travleFiles(File parent) {
        try {
            TimeUnit.SECONDS.sleep(10);
        } catch (InterruptedException e) {
            return;
        }


    }


}

5 ��结
本文介绍了三�U�简单的退出�ƈ发�Q务的�Ҏ��Q�停止线�E�；使用可取消�Q务；使用中断。毫无疑问，停止�U�程是不可取的。��用可取消的�Q务时�Q�要避免��d��׃��被阻塞而无法及�Ӟ��甚至永远无法被取消。一般地�Q�恰当地使用中断是取消�Q务的首选方式�?/span>

Sha Jiang 2013-09-21 19:11 发表评论