BlogJava-jinfeng_wang

破解Word文件密码保护的简单方法

jinfeng_wang — Wed, 06 Aug 2008 06:01:00 GMT

今天在网上找了些文档，发现被设置了文档保护，只能读，不能修改。

找到了下面的内容：

http://www.cnblogs.com/shixianyong/archive/2006/07/26/459908.html

在使用Word进行档保护时，我们经常会使用到窗体保护（工具->保护文文件），用窗体保护最为彻底，用户无法编辑，也无法进行Copy&Paste操作，前几天发布的Word文档的漏洞可以让你用很简单的方法去掉这个密码。

我们自己来测试一下：

首先创建一个Word文文件，使用窗体保护的方式保护文档，工具->保护文档->Check“仅允许在文档中进行此类编辑”->Choose“填写窗体”，此时会弹出一个密码框，输入2次密码（我这里选择123作为word文件密码），这样，该文档就已经被保护起来了。

然后我们来破解它，打开刚才创建的Word文檔，檔->另存为->选择HTML格式，存为一个HTML文档，用记事本打开该HTML文件，搜索""，你会看到5BCECF7A的字样（如果你的密码是用的123的话）。接着我们用UltraEdit或其它类似的工具打开最初受保护的Word文檔，搜索7ACFCE5B，搜索到后，都用8个0来代替，存档。

此时的Word文文件的密码就被清空了，你就可以自己取消文文件保护了，密码就不用输入了，按个回车了事。MS还没有对这个漏洞提供补丁，我觉得短期可能还无法解决这个问题，建议以后的文档不要用这个东西进行保护了。

==》

更好的做法：

然后我们来破解它，打开刚才创建的Word文檔，檔->另存为->选择HTML格式，存为一个HTML文档，用记事本打开该HTML文件，搜索""，找到相关内容，例如：7E18B4B2

直接把“7E18B4B2”
替换为"5BCECF7A"
后保存HTML文件。

再用Word打开Word文件，再选择解除文档保护，输入密码123

jinfeng_wang 2008-08-06 14:01 发表评论

Java Print Text

jinfeng_wang — Tue, 05 Aug 2008 09:13:00 GMT

import java.awt.*;
import java.awt.print.*;
import java.io.*;

/**
* Utility class to print some lines of text to the default printer. Uses some
* default font settings, and gets the page size from the PrinterJob object.
*
* Note: this little example class does not handle pagination. All the text must
* fit on a single page.
*
* This class can also be used as a standalone utility. If the main method is
* invoked, it reads lines of text from System.in, and prints them to the
* default printer.
*/

public class PrintGIF implements Printable {
/**
* Default font size, 12 point
*/
public static final int DEFAULT_FONT_SIZE = 12;

/**
* Default type name, Serif
*/
public static final String DEFAULT_FONT_NAME = "Serif";

private PrinterJob job;

private String typeName;

private int typeSize;

private Font typeFont;

private Font typeFontBold;

private String[] header;

private String[] body;

/**
* Create a TextPrinter object with the default type font and size.
*/
public PrintGIF() {
this(DEFAULT_FONT_NAME, DEFAULT_FONT_SIZE);
}

/**
* Create a TextPrinter object ready to print text with a given font and
* type size.
*/
public PrintGIF(String name, int size) {
if (size < 3 || size > 127) {
throw new IllegalArgumentException("Type size out of range");
}
typeName = name;
typeSize = size;
typeFont = new Font(typeName, Font.PLAIN, typeSize);
typeFontBold = new Font(typeName, Font.BOLD, typeSize);
job = null;
}

/**
* Initialize the printer job.
*/
protected void init() {
job = PrinterJob.getPrinterJob();
}

/**
* Initialize the print job, and return the base number of characters per
* line with the established font size and font. This is really just a
* guess, because we can't get the font metrics yet.
*/
public int getCharsPerLine() {
if (job == null) {
init();
}
PageFormat pf;
pf = job.defaultPage();
double width = pf.getImageableWidth(); // in 72nd of a pt
double ptsize = typeFont.getSize();
double ptwid = ptsize * 3 / 4;
double cnt = (width / ptwid);
return (int) (Math.round(cnt));
}

/**
* Print some text. Headers are printed first, in bold, followed by the body
* text, in plain style. If the boolean argument interactive is set to true,
* then the printer dialog gets shown.
*
* Either array may be null, in which case they are treated as empty.
*
* This method returns true if printing was initiated, or false if the user
* cancelled printer. This method may throw PrinterException if printing
* could not be started.
*/
public boolean doPrint(String[] header, String[] body, boolean interactive)
throws PrinterException {
if (job == null) {
init();
}
if (interactive)
try {
if (job.printDialog()) {
// we are going to print
} else {
// we are not going to print
return false;
}
} catch (Exception pe) {
System.err.println("Could not pop up print dialog");
// assume user wants to print anyway...
}

job.setPrintable(this);
this.header = header;
this.body = body;
job.print();
job = null; // we are no longer initialized
return true;
}

/**
* Perform printing according to the Java printing model. NEVER CALL THIS
* DIRECTLY! It will be called by the PrinterJob as necessary. This method
* always returns Printable.NO_SUCH_PAGE for any page number greater than 0.
*/
public int print(Graphics graphics, PageFormat pageFormat, int pageIndex)
throws PrinterException {
if (pageIndex != 0) {
return NO_SUCH_PAGE;
}
FontMetrics fm;
graphics.setFont(typeFont);
graphics.setColor(Color.black);
fm = graphics.getFontMetrics();

// fill in geometric and rendering guts here
int i;
double x, y;
x = pageFormat.getImageableX();
y = pageFormat.getImageableY() + fm.getMaxAscent();

// do the headings
if (header != null) {
graphics.setFont(typeFontBold);
for (i = 0; i < header.length; i++) {
graphics.drawString(header[i], (int) x, (int) y);
y += fm.getHeight();
}
}

// do the body
if (body != null) {
graphics.setFont(typeFont);
for (i = 0; i < body.length; i++) {
graphics.drawString(body[i], (int) x, (int) y);
y += fm.getHeight();
}
}

return PAGE_EXISTS;
}

/**
* Main method for testing. This main method sets up a header of
* "PRINTER TEST" and reads System.in to get body text.
*/
public static void main(String[] args) {
BufferedReader br;
java.util.List lines;

TextPrinter tp;
tp = new TextPrinter();
lines = new java.util.ArrayList();
try {
InputStreamReader isr;
isr = new InputStreamReader(System.in);
br = new BufferedReader(isr);
String line;
for (line = br.readLine(); line != null; line = br.readLine()) {
lines.add(line);
}
br.close();

System.out.println("chars per line: " + tp.getCharsPerLine());
System.out.println("attempting to print...");
String[] headers = new String[1];
headers[0] = "PRINT TEST";
String[] body = new String[lines.size()];
for (int ix = 0; ix < lines.size(); ix++) {
body[ix] = (String) (lines.get(ix));
}
boolean didit = tp.doPrint(headers, body, true);
System.out.println("doPrint returns " + didit);
} catch (Exception e) {
System.err.println("Error printing: " + e);
e.printStackTrace();
}
}
}

jinfeng_wang 2008-08-05 17:13 发表评论

在 Eclipse 中使用 5 个有用的插件来自动化代码质量分析zz

jinfeng_wang — Tue, 01 Jul 2008 04:04:00 GMT

在 Eclipse 中使用 5 个有用的插件来自动化代码质量分析

如果能在构建代码前发现代码中潜在的问题会怎么样呢？很有趣的是，Eclipse 插件中就有这样的工具，比如 JDepend 和 CheckStyle，它们能帮您在软件问题暴露前发现这些问题。

开发软件时，我的主要目标之一是：要么防止将缺陷引入代码库，要么限制缺陷的生存期；换言之，要尽早找到缺陷。很显然，越是了解如何编写更好的代码以及如何有效测试软件，就越能及早地捕捉到缺陷。我也很想要一张能发现潜在缺陷的安全之网。

将检验工具集成到构建过程（例如，使用 Ant 或 Maven）中，能够建立起一种寻找潜在缺陷的方法。尽管这种方法使一致性成为可能并超越了 IDE，但它也有一点反作用。必须在本地构建软件或等待 Continuous Integration 构建的运行。如果使用 Eclipse 插件，就可以在通过 Continuous Integration 构建或集成前发现一些这样的冲突。这就促成了我称为的渐进编程编程方式，在这种方式下，允许在编码过程中进行一定程度的质量检验 —— 再也不能比这个更早了！

本文涵盖了我所认为的 “五大” 代码分析领域：

编码标准
代码重复
代码覆盖率
依赖项分析
复杂度监控

可以用接下来的几个灵活的 Eclipse 插件来揭示这些分析领域：

CheckStyle：用于编码标准
PMD 的 CPD：帮助发现代码重复
Coverlipse：测量代码覆盖率
JDepend：提供依赖项分析
Eclipse Metric 插件：有效地查出复杂度

安装 Eclipse 插件

安装 Eclipse 插件再简单不过了，只需要几个步骤。在开始之前，最好把该插件下载站点的 URL 准备好。表 1 是本文用到的插件的列表：

表 1. 代码改进插件和相应的下载站点 URL

工具目的 Eclipse 插件的 URL

CheckStyle 编码标准分析 http://eclipse-cs.sourceforge.net/update/

Coverlipse 测试代码覆盖率 http://coverlipse.sf.net/update

CPD 复制/粘贴检验 http://pmd.sourceforge.net/eclipse/

JDepend 包依赖项分析 http://andrei.gmxhome.de/eclipse/

Metrics 复杂度监控 http://metrics.sourceforge.net/update

知道了这些有用插件的下载地址后，安装插件就是一个极简单的过程。启动 Eclipse，然后遵循下列步骤：

1、选择 Help | Software Updates | Find and Install，如图 1 所示：

图 1. 寻找并安装 Eclipse 插件

2、选择 Search for new features to install 单选按钮,单击 Next。

3、单击 New Remote Site，输入要安装的插件名和 URL（参见图 2），单击 OK，然后单击 Finish 来显示 Eclipse 更新管理器。

图 2. 配置新的远程站点

4、在 Eclipse 更新管理器中，有一个查看插件各方面特性的选项。我通常选择顶级项，如图 3 所示。选择您需要的选项并单击 Finish。Eclipse 现在安装该插件。您需要重启 Eclipse 实例。

图 3. 安装 Eclipse 插件

请遵循上述这些步骤来安装其他的 Eclipse 插件；只需改变插件名和相应的下载位置即可。

用 CheckStyle 校正标准

代码库的可维护性直接影响着软件的整个成本。另外，不佳的可维护性还会让开发人员十分头痛（进而导致开发人员的缺乏）—— 代码越容易修改，就越容易添加新的产品特性。像 CheckStyle 这样的工具可以协助寻找那些可影响到可维护性、与编码标准相冲突的地方，比方说，过大的类、太长的方法和未使用的变量等等。

使用 Eclipse 的 CheckStyle 插件的好处是能够在编码过程中了解到源代码上下文的各种编码冲突，让开发人员更可能在签入该代码前真正处理好这些冲突。您也几乎可以把 CheckStyle 插件视作一个连续的代码复查工具！

安装 CheckStyle 插件并做如下配置（参见图 4）：

1、选择 Project，然后选择 Eclipse 菜单中的 Properties 菜单项。

2、选择 CheckStyle active for this project 复选框，单击 OK。

图 4. 在 Eclipse 中配置 CheckStyle 插件

Eclipse 重新构建工作空间，并在 Eclipse 控制台中列示已发现的编码冲突，如图 5 所示：

图 5. Eclipse 中 CheckStyle 的代码冲突列表

使用 CheckStyle 插件在 Eclipse 内嵌入编码标准检验是一种很棒的方法，用这种方法可以在编码时积极地改进代码，从而在开发周期的早期发现源代码中潜在的缺陷。这么做还有更多的好处，如节省时间、减少失败，也因此会减少项目的成本。没错，这就是一种积极主动的方式！

用 Coverlipse 确认覆盖率

Coverlipse 是一个用于 Cobertura 的 Eclipse 插件，Cobertura 是一个代码覆盖率工具，可以用它来评估具有相应测试的源代码的比率。Cobertura 也提供一个 Ant 任务和 Maven 插件，但用 Cobertura，您可以在编写代码时评估代码覆盖率。您见过这样的模式吗？

通过选择 Eclipse 菜单项 Run 安装 Coverlipse 插件并将其和 JUnit 关联起来，该操作会显示一系列运行配置选项，例如 JUnit、SWT 应用程序和 Java™ 应用程序。右键单击它并选择 JUnit w/Coverlipse 节点中的 New。在这里，需要确定 JUnit 测试的位置，如图 6 所示：

图 6. 配置 Coverlipse 以获取代码覆盖率

一旦单击了 Run，Eclipse 会运行 Coverlipse 并在源代码（如图 7 所示）中嵌入标记，该标记显示了具有相关 JUnit 测试的代码部分：

图 7. Coverlipse 生成的具有嵌入类标记的报告

正如您所见，使用 Coverlipse Eclipse 插件可以更快地确定代码覆盖率。例如，这种实时数据功能有助于在将代码签入 CM 系统前更好地进行测试。这对渐进编程来说意味着什么呢？

用 CPD 捕捉代码重复

Eclipse 的 PMD 插件提供了一项叫做 CPD（或复制粘贴探测器）的功能，用于寻找重复的代码。为在 Eclipse 中使用这项便利的工具，需要安装具有 PMD 的 Eclipse 插件，该插件具有 CPD 功能。

为寻找重复的代码，请用右键单击一个 Eclipse 项目并选择 PMD | Find Suspect Cut and Paste，如图 8 所示：

图 8. 使用 CPD 插件运行复制粘贴检验

一旦运行了 CPD，您的 Eclipse 根目录下就会创建出一个 report 文件夹，其中包含一个叫做 cpd.txt 的文件，文件中列示了所有重复的代码。图 9 中是一个 cpd.txt 文件的例子：

图 9. Eclipse 插件生成的 CPD 文本文件

靠人工来寻找重复的代码是一项挑战，但使用像 CPD 这样的插件却能在编码时轻松地发现重复的代码。

使用 JDepend 进行依赖项检查

JDepend 是个可免费获取的开源工具，它为包依赖项提供面向对象的度量值，以此指明代码库的弹性。换句话说，JDepend 可有效测量一个架构的健壮性（反之，脆弱性）。

除了 Eclipse 插件，JDepend 还提供一个 Ant 任务、Maven 插件和一个 Java 应用程序，用以获取这些度量值。对于相同的信息，它们有着不同的传递机制；但 Eclipse 插件的特别之处和相应优点是：它能以更接近源代码（即，编码时）的方式传递这条信息。

图 10 演示了使用 Eclipse JDepend 插件的方法：通过右键单击源文件夹并选择 Run JDepend Analysis。一定要选择一个含源代码的源文件夹；否则看不到此菜单项。

图 10. 使用 JDepend Analysis 分析代码

图 11 显示了运行 JDepend Analysis 时生成的报告。左边显示包，右边显示针对每个包的依赖项度量值。

图 11. Eclipse 项目中的包依赖项

正如您所见，JDepend 插件提供了有助于不断观察架构可维护性变化的大量信息 —— 这其中最大的好处是您可以在编码时看到这些数据。

用 Metrics 测量复杂度

“五大”代码分析最后的一项是测量复杂度。Eclipse 提供一种叫做 Metrics 的插件，使用该插件可以进行许多有用的代码度量，包括圈复杂度度量，它用于测量方法中惟一路径的数目。

1、右键单击您的项目并选择 Properties 菜单。在结果窗口中，选择 Enable Metrics plugin 复选框并单击 OK，如图 12 所示：

图 12. 为项目配置 Metrics

2、从 Eclipse 中选择 Window 菜单打开 Metrics 视图，然后选择 Show View | Other...。

3、选择 Metrics | Metrics View 打开如图 13 中显示的窗口。您需要使用 Java 透视图并重新构建项目，从而显示这些度量值。

图 13. 打开 Eclipse 中的 Metrics View

4、单击 OK 来显示如图 14 中的窗口。

在此例中，我正在查看一个单独方法的圈复杂度。真正妙的是您可以双击 Metrics 列表中的方法，该插件会在 Eclipse 编辑器中为此方法打开源代码。这就让修正变得超级简单（如果需要的话）！

图 14. 查看方法的圈复杂度

正如我之前提到过的，Eclipse Metrics 插件还提供了许多功能强大的度量值，有助于您在开发软件的过程中改进代码 —— 可见，它是一个渐进编程意义上的插件!

合适的才是最好的

正如您从本文中看到的那样，将“五大”测量方法，即编码标准、代码重复、代码覆盖率、依赖项分析和复杂度监控，用于改进代码质量十分重要。但适合您的才是好的。请记住还有其他许多可用的 Eclipse 插件（比如 PMD 和 FindBugs）能够帮助您在开发周期的早期改进代码质量。不管您想要的工具或偏爱的方法是什么，重要的是：行动起来去积极改进代码质量并让手工代码检验的过程变得更加有效。我估计您使用这些插件一段时间后，就再也离不开它们了。

jinfeng_wang 2008-07-01 12:04 发表评论

02-06一级语法真题精解 zz

jinfeng_wang — Tue, 03 Jun 2008 06:59:00 GMT

摘要: 一级语法真题精解(2002年) 【1】出席欠席の____、同封した葉書にてお返事くださるようお願いいたします。　　1そばから　　2ないまでも　　3次第にしては　　4いかんによらず【2】私は、彼の失礼____態度に我慢ならなかった。　　1きわまった　　2きわまりない　　3きわめた　　4きわめない【3】田中さんは、この1週間と____、仕事どころではないようだ。　　1... 阅读全文

jinfeng_wang 2008-06-03 14:59 发表评论

能力考试各大考场大盘点（送给即将报名的同学） zz

jinfeng_wang — Mon, 02 Jun 2008 06:02:00 GMT

http://www.coffeejp.com/bbs/viewthread.php?tid=199523&extra=page%3D1&page=1

1020201 上海外国语大学海外考试中心

上海市东体育会路410号 021 65311900-2584 65422002 200083

【考试级别】1级

【听力设备】单人单耳机

【考场环境】150人+10个左右监考门口还有护驾的401那个1号坑

【监考态度】满意姐姐们长得都很PP=w=

【总评】考场人多外面堵车严重收废品的多听力设备没话说 401大礼堂和1楼那2个听力教室不一样平时不对外开放设备相对完好 1楼那第一个听力教室平时就有耳机zi zi的

【考点】培训部118室

【听力设备】单人单用头戴式收音机。效果非常清楚

【考场环境】考场80人距离很接近但是周围有居民楼，稍有干扰。

【监考态度】4个监考老师，非常仔细和严格。

【总评】整体感觉很好

【听力设备】校方提供耳机，声音很清楚。（3、4级好像需要自备耳机）

【考场环境】中等规模教室，大约容纳50人，一人一个小座位。看到对面一个教室是只能容纳10人左右的小教室

【监考态度】3个老师很认真负责又人性化又客气，很满意

【总评】上外口碑一向很好。这次唯一的遗憾就是听力不能调音量（起码我没找到）感觉好像声音大了点反而影响了自己听力发挥，但据其他楼考试同学反映他们那里都能调节音量。其他都非常满意，词汇还提早了几分钟发卷。还有就是座位很近，作弊特简单.....

推荐上海的考生首选上外

【听力设备】一人一个耳机，然后在教室里放录音，虽然看起来很破，但效果还真不错

【考场环境】30个人一间小教室，对面就是厕所，非常方便

【监考态度】有个考生开手机看时间，副监考居然允许了……之后来了短信，主监考才惊觉，要求关掉之后，也没咋样。唯一有点郁闷的是，考阅读语法时几个老师开始在门口聊天，虽然没多大影响，但感觉总不太好。

【总评】上外还是很不错的，就是去的时候门口实在太堵。

【听力设备】自带收音机，效果一般，有ZIZI的声音，还有回音

【考场环境】66人左右

【监考态度】还蛮好的，监考老师1男2女，有几个同学带的mp3不可以用，老师给他们几个弄来了个收音机，敞开放着听。

总的来说：比上不足，比下还算是好的了...

【考试级别】 2级

【考点】贤达学院

【听力设备】自带收音机，效果蛮好。上外的听力总体反映都不错！

【考场环境】小教室，座位之间的间隔都比较小，好像挺有利于扫到其他人的卷子的。不过本人安心做自己卷子。50人左右，有4、5缺考。。

【监考态度】三个老师，二男一女，比较人性化，态度蛮好。主监考的比较幽默。

【总评】总感觉不错，适合考试的地方。

【听力设备】校方提供耳机，声音满清楚,只是那个机器体积大了点,影响了放考卷的空间.

【考场环境】中等规模教室，大约容纳50人，一人一个独立座位。有空调不过没开.里面不冷.

【监考态度】3个老师,一个大叔,一个阿婆,一个老爷爷.大叔很好,提醒大家不要把生日写成今天的日期~~

【总评】上外真的是考生必抢之地,老师允许你在休息期去厕所,不会让你憋着.

座位虽然隔的近,但是之间有小隔断,防止作弊.

最好还是别作弊,毕竟边上不是牛人的话,会贻误难得的考试机会.

【听力设备】竟然考试前坏掉了，于是工作人员翻箱倒柜的找出了貌似爷爷奶奶那时候用的听力设备（虽然是耳机，但是感觉是初中学习电工的学生做的，耳套材质貌似自行车内胎ONZ，老式磁带机＋老式耳机＝象在做梦般的听力T_T……）

【考场环境】 20人左右容量，用的是老校舍的听力教室，外面是一条双向的小马路，考试时候（包括听力的时候）可以非常清晰、响亮的听到行人的说话声、自行车铃声、汽车喇叭声（这个声音最头疼，整个考试过程就没有断过，而且非常响，外面的马路小，所以时不时堵车，然后驾驶员就很不耐烦的按住车喇叭不放），我的听力啊、我的阅读啊当时就想抓起那古董磁带机扔向那些按喇叭的车子。

【监考态度】一开始只能一个一个上厕所（上好一个换一个），后来估计来不及了就全放行了（靠！）。外面那么吵，监考老师竟然在考阅读语法的最后半小时才注意到，跑过去关窗子，但是好像没有一点效果（我真怀疑那些窗子是不是没有装玻璃）。

【总评】听力设备算是意外，但那个考场环境心态不太好的千万别去，保证您也会抓狂！

补充一下，那栋听力大楼一进门边上竟然是厕所！而且原味十足啊

1020202 华东师范大学国外考试中心

上海中山北路3663号 021 62545332 62233151 200062

【听力设备】临时的耳机接线，一人一个大耳机（有些耳机质量不太好，可以换），放磁带。

【考场环境】大教室，考场容量接近90人，桌子是连在一起的，椅子坐得不舒服，空间小。

【监考态度】监考4人，中间休息5分钟，可以上厕所

【总评】听力音质还可以，就是坐的环境不舒服，容易腰酸背痛。

【考试级别】1级

【听力设备】学校提供的耳机，声音相当清晰，轻重正好

【考场环境】还可以，感觉桌子比较窄

【监考态度】比较严格

【总评】环境不错，厕所拥挤，听力设备好，上海考生可以作为首选

【考试级别】 3级

【听力设备】小型磁带机（音质还可以，只是监考人员不会使用磁带机，还找了3～4个人来一起搞定，延误了10多分钟。）

【考场环境】 50人容量

【监考态度】进了考场就不让上厕所，直到考试结束。（差点憋死我）

【总评】总体硬件还行，只是监考人员的素质有待提高。

【听力设备】磁带加扩音音响。

【考场环境】较宽敞，听力质量以磁带的水准看尚可。

【监考态度】比较严，考试答题时间卡得很紧，但中间留有上厕所的时间。

【总评】还可以，据说下次不再设在华师大位于上海市区本部了，改在上海闵行校区了。那里质量如何，暂不清楚。

【考试级别】一级

【听力设备】一人配发一个耳机,因为是串联的,所以整体调节音量

【考场环境】我坐30来个人的小教室,当天阳光不错,我靠窗,还能晒晒太阳~哈哈

【监考态度】老师很随和,做词汇的时候还提早发了!哈哈!

【总评】不是同一个学校就一样,考场总会有各种不定因素的!

【考试级别】二级

【听力设备】本来自带后来变成了录音机（效果不太好）

【考场环境】40人左右一个教室有钟

【监考态度】没啥好说很不遵守时间规定

【总评】C----以后不会再去了吧

PS 考试时间不遵守规定的每个考场不一我是8点40开始

接着导致听力在教室外面有其他题目的声音

休息也不正常一部分3分钟最多

【考试级别】日语2级

【考点】田家炳教育书院

【听力设备】一般偏下，大广播录音，中间有N多出录音卡壳，明显带有录音痕迹，且有杂音

【考场环境】一般

【监考态度】一般

【总评】一般，听力设备不理想

【级别】2级

【听力设备】天花板上两个大音箱

【考场环境】算是阶梯教室了，考场90人

【监考态度】监考5名，中间可以上厕所

【总评】都还可以，就是听力设备太次，天花板上的音箱的声音传到耳朵里都糊掉了，那个男的声音几乎听不清

【听力设备】单人单用头戴式收音机。效果非常清楚，尤如听mp3

【考场环境】较挤，课桌比较旧

【监考态度】监考两名，听力和阅读之间才可以上厕所

【总评】听力还可以，就是教室条件一般

1020203 上海海事大学考试中心

上海浦东大道1550号 021 68532589 68539591 200135

【考试级别】1级

【听力设备】用的是电脑直接放墙上挂着的大音箱,效果还可以,略有些杂音

【考场环境】是语音教室还可以

【监考态度】老师不错,收卷时看我还在图就先收后面的了,让我弄好再收

【总评】还可以吧,明年还去这里考(因为过不了,汗)

【考试级别】2级

【听力设备】我在阶梯教室听的,清楚到是还行,不过就是有点空旷的回音,不是很影响的!

【考场环境】中间休息没有出去过,不知道厕所情况!!教室的话,硬件还可以

【监考态度】有5个监考的,2个老一点的可能是老师,还有3个年轻的,可能是学生.态度都不好不坏,没有正面接触~~

【总评】刚去的时候是按照准考证上面写的教室去的,可是一去发现我的教室写错了.(事先写教室的人没有看清楚我的准考证号码,搞错了)慌死我了~~还好有个年轻的考场人员告诉我,我的号码是上一个教室.事先的准备工作他们做的不缜密,不过现场工作人员还不错.

【考试级别】一级

【考点】综合楼414

【听力设备】统一耳机，声音较响，我不太习惯而且不能调节,但是音质还是很不错的,清晰

【考场环境】座位太挤了,考试的时候都会碰到旁边的人

【监考态度】监考老师简直就是掐着秒表宣布开考的,人不错

【总评】还可以

1020204 华东理工大学考试中心

上海市梅陇路130号 021 64250798 200237

【考试级别】2级

【听力设备】录音机

【考场环境】阶梯教室，位子做得比较空旷，录音机没有回音

【监考态度】一位老头子监考老师，2位女老师。态度相当不错，考每个部分的时候考场规则都会读一遍，考试时间也很仔细的提醒。每个部分结束可以上厕所，还会提醒你什么时候进教室。由于本人怕热，所以穿短袖上场，一个女老师还说：哟，你这么热呀。。。OTL

【考试级别】 3

【听力设备】录音机,效果还可以,就是录音有点阴阳怪气的

【考场环境】我是大考场,阶梯教室,大概有100个人左右

【监考态度】阶梯教室,监考多,有6个,管的好象很松,连准考证身份证都没核对

【总评】不错

【考试级别】2

【听力设备】讲桌上放录音机，挺清楚地，但因教室不隔音会有其他教室放听力的干扰，

【考场环境】楼破一点，桌椅挺新，小教室坐20多人

【监考态度】老师不错，可以提前看卷子，听力也提前放了一会儿，中间休息可以待在教室里，休息的时候会发卷子，这是就可以看了，说是不能提前作，但先写了也没管

【总评】85分，总体感觉很好，老师态度也很好，就是听力有些干扰，因为其他教室听力放太大声了，稍微有点混。

020205 上海交通大学外国语学院

上海市东川路800号（闵行校区） 021 62933474 200030

【听力设备】大教室里的广播用大喇叭（比较清楚，考不好关键在自己）

【考场环境】不错（考生虽然多了点）

【监考态度】很随和（两个学生）

【总评】还不错，就是你必须去徐汇校区拿了准考证在去闵行考试，来回要奔波一下

【考试级别】2

【听力设备】外放音箱,還不錯,覺得聽的蠻清楚的,雜音也不多,不過我坐比較中間位置,不知道坐後面的怎麼樣

【考场环境】算是蠻乾淨的,而且50、60人左右的大教室,看上去也不是很擠,就是椅子非常硬,3個多小時考得我那叫一個腰酸背痛結果還沒考出來

【监考态度】3个人,態度各方面都還可以,也不是管得特別緊,每段考試中間休息15分鐘,可以去上廁所,不過考試的時候貌似隱約感覺有類似閃光燈一樣的亮了一下,至今8曉得是什麼事,難道是我的錯覺麼?

【总评】整體還算可以的,明年再奮斗的話還會考慮報那裡,就是交通不太方便,我們家到那裡得1號線換5號線,再攔量車過去,結果考完出來後根本沒車攔,只能走了N多路去換5號線,那車叫一個擠啊,整個花了我快3個小時才到的家

【考试级别】一级

【听力设备】两个大喇叭,这次很不幸,喇叭坏掉两次

【考场环境】教师倒是很大很干净,就是座位不能移动,考完屁股坐得很疼

【监考态度】监考老师完全没有经验,题目发得完了,遇到问题也不会及时处理

【总评】交通太远了,轻轨也要走好久,别的公车也不太方便.总以为喇叭总比录音机好点,结果,喇叭竟然会中途坏掉...

【考试级别】一级

【听力设备】喇叭(不是音箱)杂音是肯定有的,但还是能听清

【考场环境】50的教室,旷工的应该有四分之一

【监考态度】二个小伙子,人不错,但不懂规矩.听力的时候,竟然像猴子一样进进出出教室,我坐门口...........

【总评】去交大总要有点风险,总有一两个教室喇叭是会出问题的

【考试级别】2

【考点】D楼107

【听力设备】大喇叭

【考场环境】大概60多个人左右的大教室

【监考态度】三名监考老师，（一个老师，两个好像是研究生）休息时候可以随意出去，老师也不窃窃私语，走动得多不多我倒没注意，非常负责提醒同学填写东西不要填错。严不严倒不好说，因为自己没动歪脑筋~

【总评】非常不错的考场，听力非常清楚，监考也非常好。

【考试级别】1级

【听力设备】悬挂式大喇叭 2个

【考场环境】大阶梯教室有100来号人

【监考态度】老师也就发卷子收卷子座在靠后点的如果有人认识作弊应该没问题哈哈玩笑

【总评】离市区很远早上出门要很早到了那边没有明确的指示标志而且考场蛮深的有点路程考完后大家都要挤轻轨拥堵状况实在太恐怖 12点半考完等同学一起走到家下午15:30 家在市中心所以这段路实在是太难熬了

【考试级别】1级

【听力设备】2个音箱，教室大所以有回音，有破音，总体效果马马虎虎吧

【考场环境】大教室

【监考态度】3个监考，中场休息可以去厕所，MS都是第1次监考，听力卷子差点没及时发……

【总评】环境可以，监考素质不行

【考试级别】三级

【听力设备】教室里有大喇叭，音响效果不错

【考场环境】多媒体教室，共设考生89人，教室设备、环境绝对不错！

【监考态度】认真是蛮认真，就是两个男的监考有点傻，一看就是学生。

【总评】那两个男的监考真的有点傻，刚开始就答题卡发错，他们不知道答题卡上事先已经将名字打印上去的，后来收掉重新发！被那个女主考狂骂！呵呵。教室有摄像头的，一直有人监控的。有点恐怖！总的来说不错！！！

1020206 上海同济大学教务处

上海市四平路1239号 021 65983634 200092

【听力设备】自备收音机

【考场环境】硬件设施还不错，20个人左右吧

【监考态度】老师还算亲切，两个老师，就是有点马虎，差点少收了我的听力卷子

【总评】总体不错，要是今年不过，明年可以考虑再过来考

【听力设备】自备收音机

【考场环境】干净、舒适

【监考态度】老师态度很好，早5分钟发考卷。虽然老师说不许提前打题，但是只是说说而已。

【总评】感觉挺不错。

【考试级别】1

【听力设备】自带FM调频收音机，听力的时候身体不能动，否则会影响调频，听力过程中有两三下吱吱的噪音，直接导致两道题听不清，感觉调频的方式还是让人不太放心

【考场环境】还可以

【监考态度】不严，可以提前打开试卷

【总评】听力设备不好，不推荐

没空调、中间休息时可以去上厕所监考老师是两个老太太，满和蔼可亲的

就是座位不太好，前后座位是连着的听力是有杂音，一个考场里有四五个人不能接受到。

我开始时也收不到，后来才好的

1020207 上海大学海外考试中心 上海市上大路99号 021 66133195 200444

【听力设备】校方提供收音机押金50可能是电池钱5元，声音效果很好就是我都没听懂

【考场环境】30人小教室环境还不错，就是一排两个人的距离太近稍微斜眼就能看到对方答题纸。

可惜和我一排的比我还弱只有他照我抄了

【监考态度】态度很好就是老师的手表慢了发卷纸不即时，还算严格吧我旁边照我抄的那位被警告过一次，不过还照样抄。

感觉不是很严。中间不许上厕所。

【总评】还可以

【考试级别】：一级

【听力设备】：上大自产的收音机（因为是上大广播台播的，频率比较低，要是有全频的收音机也可以，不强制），声音很清楚，对听力考试满好的。

【考场环境】：阶梯教室，间隔不算大，坐着很舒服，因为郊区，稍微有点冷。每部分考试中间都可以去厕所。

【监考态度】：都是年轻教师，所以比较羞涩。不大出声音，没有干扰的情况发生。

【总评】：因为是母校，特地选哪里考的。上海大学的宝山校区环境是很好的，比较干净，就是稍微远了点，但是交通还算方便，要是明年考的xdjm们还有7号线可以坐，更方便了。一三级是自带的收音机，二四级不用，可能是语音教室。

【听力设备】竟然要自己花钱去上大租！！

【考场环境】一般

【监考态度】大考场，监考老师多4个以上

【总评】上大想要前要疯了，听力考试竟然要花钱，不是上大的收音机不能收听

【听力设备】收音机，有点小杂音，基本还可以。但是收音机是以租借的方式给考生使用的，说是不准自带。在领取准考证时收取每名考生55元，说是在考试完后回收收音机再退回50块钱押金。只听45分钟就要五块钱，真黑！华南师大也是用收音机啊，音质好而且还是免费提供！

【考场环境】大考场,阶梯教室,80人一间。还算宽松。

【监考态度】监考老师3人，两男一女,监考不严，有人“侧目”,考试中可以上卫生间。其中一男为日语老师，操一口流利的吴侬口音日语。在阅读部分开考时监考老师一边回收收音机一边返还考生押金，不停发出声响。并在收音机全部回收之后在讲台数机子，讨论机子的数量问题。仿佛那里不是考场而是菜市。顿时，男人声、女人声、收音机摩擦声、塑料袋被蹂躏声......声声不绝于耳（回收过程持续超过半小时），时而还传来个别老师在门口呼唤监考老师之声...... 严重影响考生情绪，众考生均怒而不言——君子报仇十年不晚。

【总评】即将邮件投诉到教育部海外考试中心

【听力设备】租借学校专用的收音机，租借费50元（事后退还），电池费5元（不退还），听力还蛮清楚地

【考场环境】偌大的阶梯教室，（教室朝北12月的时候蛮冷的，而且没有空调）因为学校太大，开考前很多人走错考场，建议预先踩点一下

【监考态度】似乎从没监考过能力考试似的考生问考场在哪里他们一问三不知问座位的大概方向也不知道，方向感差的人自求多福。最搞笑的是听力结束后第一件事不是收考卷，是一个监考拿着一叠50元人民币在考场里一个一个办理退还收音机的手续，貌似一直到考第三场阅读的时候还在退钱收收音机，考生的情绪可想而知。

【总评】70（主要是她没在我考阅读的时候来问我要收音机，不然。。。）

【听力设备】校台，清晰。（需要他们的收音机，可以借，押金考完会退，5块的手续费，推荐自己带耳机和电池）

【考场环境】环境很漂亮，这没话说。对我来说路远，而且交通恐怖，校园很大，去拿准考证的时候一定要把校园熟悉一下，牢记自己的考场位置和最方便的路线

【监考态度】监考负责！说流程和事项以外，我们的监考还特意再次提醒我们听力的答题方式（就是那个图一个对的然后图三个错的题型，他反复提醒的）

【总评】除了交通以外，其他可以说上海大学是个不错的考场！（90分吧）

去上海大学考试，给我最深印象就是：交通！条件好的同学，自己车子过去是最好的选择我认为，我是坐公交去的，说说我路途上的体会吧。

估计5点45我起床的，地铁到车站，然后去坐去上海大学的公交，是终点站，有位子坐（别小看这个位子），第一站还好，第2站开始，车厢基本85%已满，第 3站就已经饱和（买票都是前门给司机，然后去中门上车的），途中除了有个别乘客需要下车，车子基本不停站的（这也是我推荐终点站的一个比较大的理由，中途坐不上车就拖大了，taxi几乎是叫不到的），然后就这样被挤着去的，车内空气极其的浑浊，如果有轻微的晕车的同学建议带好晕车药，平时不晕或偶尔晕在那车厢里就难说了。（地铁到哪站我实在是记不起来了，真的很对不住大家）

回来：

回来我这有2个建议，一个是坐刚才那辆来的车（不是回去，而是继续乘到终点站，再从那边的终点站乘回），不然一考完，基本是挤不上车的，多出2块钱吧，省好多时间的。

第二个就是和几个同学一起拼个taxi（很多同学基本都是要去地铁的，所以很容易找的，那天我没坐taxi，所以也无法知道大概的费用是多少）

还想提一下考试中的情况（至少我的教室是这样的），情况就是，在考第3部分阅读文法时，老师会在考试期间来收取收音机和准考证（他的目的是以便考完可以直接退钱让我们早点走，当然他收取准考证只是为了退收音机钱的时候能报上我们的名字，直接还给我们的，不用担心），但我觉得这个挺烦人的，即使再轻微的动作，这样多少会有一丝让人分心的，至少对我来说是这样的。

友情提示：交通恐怖，带好吃的东西，那边几乎找不到买东西的地方的，我到家是下午近4点（我在徐汇）

【考试级别】 2级

【听力设备】中控台接到墙上的大喇叭，听力算是毁了，还有一个喇叭坏了

【考场环境】阶梯教室，人太多了，容易出状况，听力的时候还有人在刷刷地翻卷子，真想杀了那个人

【监考态度】管理较严，但是发卷子和放录音有点晚

【总评】这种地方考2级还不成问题，考1级最好要更好的听力设备

【听力设备】阶梯教室中前面两个大喇叭。

【考场环境】不怎么好，很多人缺考。

【监考态度】老师好象搞不太清楚状况，卷子都会发错。

【总评】不算很好，让我打分最多只有60分。进场之前就乱七八糟的，后来听力时先开始那个大喇叭糊涂的要死，根本就听不清楚，后来折腾了几分钟总算是清楚点了。跟我去年在华师大考时的条件比差不多了，老师也不是很敬业，卷子竟然还会发错……严重影响我当时的发挥，哎！

1020208 上海财经大学

国定路777号 021 65651652 200433

【考试级别】二级

【听力设备】不允许自带收银机耶。。教室比较小。。所以还挺清晰的

【考场环境】破烂的桌子，而且很窄小，阳光很充足啊。。。真暖和

【监考态度】随和的老太。。提前10分钟发了卷。。我们打开做也不管，交卷后。。后面一个还在接着涂。。她就耐心的等着。。狂汗！

【总评】不错啦。。。可以考虑来年一级继续！！

【听力设备】录音机功放，磁带

【考场环境】每个考场30人，有空调

【监考态度】监考两名，每次交卷后都可以上厕所

【总评】环境还可以，就是听力设备太次

【考试级别】一级

【听力设备】录音机公放

【考场环境】每个考场大概三四十人,一教有空调(不开),二教没有空调(今年是一级在一教考,两级在二教考的)

【监考态度】监考两名，每次交卷后都可以上厕所

【总评】环境还可以

jinfeng_wang 2008-06-02 14:02 发表评论

Java Thread.interrupt 害人！中断JAVA线程（zz）

jinfeng_wang — Sun, 27 Apr 2008 08:16:00 GMT

程序是很简易的。然而，在编程人员面前，多线程呈现出了一组新的难题，如果没有被恰当的解决，将导致意外的行为以及细微的、难以发现的错误。
      在本篇文章中，我们针对这些难题之一：如何中断一个正在运行的线程。

背景
    中断（Interrupt）一个线程意味着在该线程完成任务之前停止其正在进行的一切，有效地中止其当前的操作。线程是死亡、还是等待新的任务或是继续运行至下一步，就取决于这个程序。虽然初次看来它可能显得简单，但是，你必须进行一些预警以实现期望的结果。你最好还是牢记以下的几点告诫。

    首先，忘掉Thread.stop方法。虽然它确实停止了一个正在运行的线程，然而，这种方法是不安全也是不受提倡的，这意味着，在未来的JAVA版本中，它将不复存在。

一些轻率的家伙可能被另一种方法Thread.interrupt所迷惑。尽管，其名称似乎在暗示着什么，然而，这种方法并不会中断一个正在运行的线程（待会将进一步说明），正如Listing A中描述的那样。它创建了一个线程，并且试图使用Thread.interrupt方法停止该线程。Thread.sleep()方法的调用，为线程的初始化和中止提供了充裕的时间。线程本身并不参与任何有用的操作。

class Example1 extends Thread {
            boolean stop=false;
            public static void main( String args[] ) throws Exception {
            Example1 thread = new Example1();
            System.out.println( "Starting thread..." );
            thread.start();
            Thread.sleep( 3000 );
            System.out.println( "Interrupting thread..." );
            thread.interrupt();
            Thread.sleep( 3000 );
            System.out.println("Stopping application..." );
            //System.exit(0);
            }
            public void run() {
            while(!stop){
            System.out.println( "Thread is running..." );
            long time = System.currentTimeMillis();
            while((System.currentTimeMillis()-time < 1000)) {
            }
            }
            System.out.println("Thread exiting under request..." );
            }
            }

如果你运行了Listing A中的代码，你将在控制台看到以下输出：

Starting thread...

Thread is running...

Thread is running...

Thread is running...

Interrupting thread...

Thread is running...

Thread is running...

Thread is running...

Stopping application...

Thread is running...

Thread is running...

Thread is running...
...............................
甚至，在Thread.interrupt()被调用后，线程仍然继续运行。

真正地中断一个线程

    中断线程最好的，最受推荐的方式是，使用共享变量（shared variable）发出信号，告诉线程必须停止正在运行的任务。线程必须周期性的核查这一变量（尤其在冗余操作期间），然后有秩序地中止任务。Listing B描述了这一方式。

Listing B
class Example2 extends Thread {

  volatile boolean stop = false;

  public static void main( String args[] ) throws Exception {

    Example2 thread = new Example2();

   System.out.println( "Starting thread..." );

   thread.start();

   Thread.sleep( 3000 );

   System.out.println( "Asking thread to stop..." );

   thread.stop = true;

   Thread.sleep( 3000 );

   System.out.println( "Stopping application..." );

   //System.exit( 0 );

  }

  public void run() {

    while ( !stop ) {

     System.out.println( "Thread is running..." );

      long time = System.currentTimeMillis();

      while ( (System.currentTimeMillis()-time < 1000) && (!stop) ) {

      }

    }

   System.out.println( "Thread exiting under request..." );

  }

}

运行Listing B中的代码将产生如下输出（注意线程是如何有秩序的退出的）

Starting thread...

Thread is running...

Thread is running...

Thread is running...

Asking thread to stop...

Thread exiting under request...

Stopping application...

   虽然该方法要求一些编码，但并不难实现。同时，它给予线程机会进行必要的清理工作，这在任何一个多线程应用程序中都是绝对需要的。请确认将共享变量定义成volatile 类型或将对它的一切访问封入同步的块/方法（synchronized blocks/methods）中。

到目前为止一切顺利!但是，当线程等待某些事件发生而被阻塞，又会发生什么？当然，如果线程被阻塞，它便不能核查共享变量，也就不能停止。这在许多情况下会发生，例如调用Object.wait()、ServerSocket.accept()和DatagramSocket.receive()时，这里仅举出一些。

他们都可能永久的阻塞线程。即使发生超时，在超时期满之前持续等待也是不可行和不适当的，所以，要使用某种机制使得线程更早地退出被阻塞的状态。

很不幸运，不存在这样一种机制对所有的情况都适用，但是，根据情况不同却可以使用特定的技术。在下面的环节，我将解答一下最普遍的例子。

使用Thread.interrupt()中断线程

  正如Listing A中所描述的，Thread.interrupt()方法不会中断一个正在运行的线程。这一方法实际上完成的是，在线程受到阻塞时抛出一个中断信号，这样线程就得以退出阻塞的状态。更确切的说，如果线程被Object.wait, Thread.join和Thread.sleep三种方法之一阻塞，那么，它将接收到一个中断异常（InterruptedException），从而提早地终结被阻塞状态。

    因此，如果线程被上述几种方法阻塞，正确的停止线程方式是设置共享变量，并调用interrupt()（注意变量应该先设置）。如果线程没有被阻塞，这时调用interrupt()将不起作用；否则，线程就将得到异常（该线程必须事先预备好处理此状况），接着逃离阻塞状态。在任何一种情况中，最后线程都将检查共享变量然后再停止。Listing C这个示例描述了该技术。

Listing C
class Example3 extends Thread {

  volatile boolean stop = false;

  public static void main( String args[] ) throws Exception {

   Example3 thread = new Example3();

   System.out.println( "Starting thread..." );

   thread.start();

   Thread.sleep( 3000 );

   System.out.println( "Asking thread to stop..." );

   thread.stop = true;//如果线程阻塞，将不会检查此变量

   thread.interrupt();

   Thread.sleep( 3000 );

   System.out.println( "Stopping application..." );

   //System.exit( 0 );

  }

  public void run() {

    while ( !stop ) {

     System.out.println( "Thread running..." );

      try {

      Thread.sleep( 1000 );

      } catch ( InterruptedException e ) {

      System.out.println( "Thread interrupted..." );

      }

    }

   System.out.println( "Thread exiting under request..." );

  }

}

一旦Listing C中的Thread.interrupt()被调用，线程便收到一个异常，于是逃离了阻塞状态并确定应该停止。运行以上代码将得到下面的输出：

Starting thread...

Thread running...

Thread running...

Thread running...

Asking thread to stop...

Thread interrupted...

Thread exiting under request...

Stopping application...

中断I/O操作
    然而，如果线程在I/O操作进行时被阻塞，又会如何？I/O操作可以阻塞线程一段相当长的时间，特别是牵扯到网络应用时。例如，服务器可能需要等待一个请求（request），又或者，一个网络应用程序可能要等待远端主机的响应。

如果你正使用通道（channels）（这是在Java 1.4中引入的新的I/O API），那么被阻塞的线程将收到一个ClosedByInterruptException异常。如果情况是这样，其代码的逻辑和第三个例子中的是一样的，只是异常不同而已。

但是，你可能正使用Java1.0之前就存在的传统的I/O，而且要求更多的工作。既然这样，Thread.interrupt()将不起作用，因为线程将不会退出被阻塞状态。Listing D描述了这一行为。尽管interrupt()被调用，线程也不会退出被阻塞状态

Listing D
import java.io.*;

class Example4 extends Thread {

  public static void main( String args[] ) throws Exception {

    Example4 thread = new Example4();

   System.out.println( "Starting thread..." );

   thread.start();

   Thread.sleep( 3000 );

   System.out.println( "Interrupting thread..." );

   thread.interrupt();

   Thread.sleep( 3000 );

   System.out.println( "Stopping application..." );

   //System.exit( 0 );

  }

  public void run() {

   ServerSocket socket;

    try {

      socket = new ServerSocket(7856);

    } catch ( IOException e ) {

     System.out.println( "Could not create the socket..." );

      return;

    }

    while ( true ) {

     System.out.println( "Waiting for connection..." );

      try {

       Socket sock = socket.accept();

      } catch ( IOException e ) {

      System.out.println( "accept() failed or interrupted..." );

      }

    }

  }

}

   很幸运，Java平台为这种情形提供了一项解决方案，即调用阻塞该线程的套接字的close()方法。在这种情形下，如果线程被I/O操作阻塞，该线程将接收到一个SocketException异常，这与使用interrupt()方法引起一个InterruptedException异常被抛出非常相似。

唯一要说明的是，必须存在socket的引用（reference），只有这样close()方法才能被调用。这意味着socket对象必须被共享。Listing E描述了这一情形。运行逻辑和以前的示例是相同的。

Listing E
import java.net.*;
import java.io.*;
class Example5 extends Thread {
  volatile boolean stop = false;
  volatile ServerSocket socket;
  public static void main( String args[] ) throws Exception {
    Example5 thread = new Example5();
   System.out.println( "Starting thread..." );
   thread.start();
   Thread.sleep( 3000 );
   System.out.println( "Asking thread to stop..." );
   thread.stop = true;
   thread.socket.close();
   Thread.sleep( 3000 );
   System.out.println( "Stopping application..." );
   //System.exit( 0 );
  }
  public void run() {
    try {
      socket = new ServerSocket(7856);
    } catch ( IOException e ) {
     System.out.println( "Could not create the socket..." );
      return;
    }
    while ( !stop ) {
     System.out.println( "Waiting for connection..." );
      try {
       Socket sock = socket.accept();
      } catch ( IOException e ) {
      System.out.println( "accept() failed or interrupted..." );
      }
    }
   System.out.println( "Thread exiting under request..." );
  }
}
以下是运行Listing E中代码后的输出：

Starting thread...

Waiting for connection...

Asking thread to stop...

accept() failed or interrupted...

Thread exiting under request...

Stopping application...

多线程是一个强大的工具，然而它正呈现出一系列难题。其中之一是如何中断一个正在运行的线程。如果恰当地实现，使用上述技术中断线程将比使用Java平台上已经提供的内嵌操作更为简单。

============================================

Writing multithreaded programs in Java, with its built-in support for threads, is fairly straightforward. However, multithreading presents a whole set of new challenges to the programmer that, if not correctly addressed, can lead to unexpected behavior and subtle, hard-to-find errors. In this article, we address one of those challenges: how to interrupt a running thread.

Background
Interrupting a thread means stopping what it is doing before it has completed its task, effectively aborting its current operation. Whether the thread dies, waits for new tasks, or goes on to the next step depends on the application.

Although it may seem simple at first, you must take some precautions in order to achieve the desired result. There are some caveats you must be aware of as well.

First of all, forget the Thread.stop method. Although it indeed stops a running thread, the method is unsafe and was deprecated, which means it may not be available in future versions of the Java.

Another method that can be confusing for the unadvised is Thread.interrupt. Despite what its name may imply, the method does not interrupt a running thread (more on this later), as Listing A demonstrates. It creates a thread and tries to stop it using Thread.interrupt. The calls to Thread.sleep() give plenty of time for the thread initialization and termination. The thread itself does not do anything useful.

If you run the code in Listing A, you should see something like this on your console:
Starting thread...
Thread is running...
Thread is running...
Thread is running...
Interrupting thread...
Thread is running...
Thread is running...
Thread is running...
Stopping application...

Even after Thread.interrupt() is called, the thread continues to run for a while.

Really interrupting a thread
The best, recommended way to interrupt a thread is to use a shared variable to signal that it must stop what it is doing. The thread must check the variable periodically, especially during lengthy operations, and terminate its task in an orderly manner. Listing B demonstrates this technique.

Running the code in Listing B will generate output like this (notice how the thread exits in an orderly fashion):
Starting thread...
Thread is running...
Thread is running...
Thread is running...
Asking thread to stop...
Thread exiting under request...
Stopping application...

Although this method requires some coding, it is not difficult to implement and give the thread the opportunity to do any cleanup needed, which is an absolute requirement for any multithreaded application. Just be sure to declare the shared variable as volatile or enclose any access to it into synchronized blocks/methods.

So far, so good! But what happens if the thread is blocked waiting for some event? Of course, if the thread is blocked, it can't check the shared variable and can't stop. There are plenty of situations when that may occur, such as calling Object.wait(), ServerSocket.accept(), and DatagramSocket.receive(), to name a few.

They all can block the thread forever. Even if a timeout is employed, it may not be feasible or desirable to wait until the timeout expires, so a mechanism to prematurely exit the blocked state must be used.

Unfortunately there is no such mechanism that works for all cases, but the particular technique to use depends on each situation. In the following sections, I'll give solutions for the most common cases.

Interrupting a thread with Thread.interrupt()
As demonstrated in Listing A, the method Thread.interrupt() does not interrupt a running thread. What the method actually does is to throw an interrupt if the thread is blocked, so that it exits the blocked state. More precisely, if the thread is blocked at one of the methods Object.wait, Thread.join, or Thread.sleep, it receives an InterruptedException, thus terminating the blocking method prematurely.

So, if a thread blocks in one of the aforementioned methods, the correct way to stop it is to set the shared variable and then call the interrupt() method on it (notice that it is important to set the variable first). If the thread is not blocked, calling interrupt() will not hurt; otherwise, the thread will get an exception (the thread must be prepared to handle this condition) and escape the blocked state. In either case, eventually the thread will test the shared variable and stop. Listing C is a simple example that demonstrates this technique.

As soon as Thread.interrupt() is called in Listing C, the thread gets an exception so that it escapes the blocked state and determines that it should stop. Running this code produces output like this:
Starting thread...
Thread running...
Thread running...
Thread running...
Asking thread to stop...
Thread interrupted...
Thread exiting under request...
Stopping application...

Interrupting an I/O operation
But what happens if the thread is blocked on an I/O operation? I/O can block a thread for a considerable amount of time, particularly if network communication is involved. For example, a server may be waiting for a request, or a network application may be waiting for an answer from a remote host.

If you're using channels, available with the new I/O API introduced in Java 1.4, the blocked thread will get a ClosedByInterruptException exception. If that is the case, the logic is the same as that used in the third example—only the exception is different.

But you might be using the traditional I/O available since Java 1.0, since the new I/O is so recent and requires more work. In this case, Thread.interrupt() doesn't help, since the thread will not exit the blocked state. Listing D demonstrates that behavior. Although the interrupt() method is called, the thread does not exit the blocked state.

Fortunately, the Java Platform provides a solution for that case by calling the close() method of the socket the thread is blocked in. In this case, if the thread is blocked in an I/O operation, the thread will get a SocketException exception, much like the interrupt() method causes an InterruptedException to be thrown.

The only caveat is that a reference to the socket must be available so that its close() method can be called. That means the socket object must also be shared. Listing E demonstrates this case. The logic is the same as in the examples presented so far.

And here's the sample output you can expect from running Listing E:
Starting thread...
Waiting for connection...
Asking thread to stop...
accept() failed or interrupted...
Thread exiting under request...
Stopping application...

Multithreading is a powerful tool, but it presents its own set of challenges. One of these is how to interrupt a running thread. If properly implemented, these techniques make interrupting a thread no more difficult than using the built-in operations already provided by the Java Platform.

jinfeng_wang 2008-04-27 16:16 发表评论

Mylyn 2.0，第 1 部分: 集成的任务管理

jinfeng_wang — Tue, 25 Mar 2008 10:16:00 GMT

http://www.ibm.com/developerworks/cn/java/j-mylyn1/

jinfeng_wang 2008-03-25 18:16 发表评论

Mylyn 2.0，第 2 部分: 自动上下文管理

jinfeng_wang — Tue, 25 Mar 2008 10:16:00 GMT

http://www.ibm.com/developerworks/cn/java/j-mylyn2/

jinfeng_wang 2008-03-25 18:16 发表评论

develop tools

jinfeng_wang — Tue, 25 Mar 2008 10:10:00 GMT

	JIRA 专业的缺陷跟踪与项目管理软件（Issue Tracking）
	Confluence 团队协作与知识共享（企业Wiki软件）
	Bamboo 持续集成服务器（CI Build Server）
	Crowd 单点登录工具（SSO - Simplified）
	Clover 强大并高度可配置的代码覆盖分析工具
	Crucible 有效的代码评审
	FishEye 源代码库深度查看

jinfeng_wang 2008-03-25 18:10 发表评论

Windows CMD Console 字符集的修改

jinfeng_wang — Mon, 24 Mar 2008 10:26:00 GMT

查看Console的字符集编码：右键 CMD的对话框标题栏，查看属性中的option -> current code page

修改注册表：
[HKEY_CURRENT_USER/Console/%SystemRoot%_system32_cmd.exe] "CodePage"=dword:000003a8

修改code为932-->日语，936-->中文GBK

jinfeng_wang 2008-03-24 18:26 发表评论

BlogJava-jinfeng_wang

破解Word文件密码保护的简单方法

Java Print Text

在 Eclipse 中使用 5 个有用的插件来自动化代码质量分析zz

02-06一级语法真题精解 zz

能力考试各大考场大盘点（送给即将报名的同学） zz

Java Thread.interrupt 害人！ 中断JAVA线程（zz）

Mylyn 2.0，第 1 部分: 集成的任务管理

Mylyn 2.0，第 2 部分: 自动上下文管理

develop tools

Windows CMD Console 字符集的修改

Java Thread.interrupt 害人！中断JAVA线程（zz）