阳光男孩

1顶一下编者按：程序员和软件测试员之间的关系无须多言。这些经典回复是国外程序员总结分享的，“全球通用”。 20. “That’s weird…” 很奇怪…… 19. “It’s never done that before.” 以前没这样过的。 18. “It worked yesterday.” 昨天还好好的。 17. “How is that possible?” 那怎么可能？（怎么会出问题？） 16. “It must be a hardware problem.” 这一定是硬件问题。 15. “What...[阅读全文]

编者按：程序员和软件测试员之间的关系无须多言。这些经典回复是国外程序员总结分享的，“全球通用”。

20. “That’s weird…” 很奇怪……
19. “It’s never done that before.” 以前没这样过的。
18. “It worked yesterday.” 昨天还好好的。
17. “How is that possible?” 那怎么可能？（怎么会出问题？）
16. “It must be a hardware problem.” 这一定是硬件问题。

15. “What did you type in wrong to get it to crash?” 你输入什么东西后才崩溃的？
14. “There is something funky in your data.” 你的数据有问题。
13. “I haven’t touched that module in weeks!” 我好几个礼拜没动那个程序了！
12. “You must have the wrong version.” 你一定在用错误的版本。
11. “It’s just some unlucky coincidence.” 这只是凑巧。

10. “I can’t test everything!” 我无法测试所有东西。（我的机器环境下，无法测试所有的可能情况。）
09. “THIS can’t be the source of THAT.” “这”不可能是问题的原因。
08. “It works, but it hasn’t been tested.” 程序能用，不过还没有测试。
07. “Somebody must have changed my code.” 一定有人改了我的代码。
06. “Did you check for a virus on your system?” 你的电脑扫描病毒了么？

05. “Even though it doesn’t work, how does it feel? 即便程序不行了，（你觉得）程序写得如何？
04. “You can’t use that version on your system.” 你不能在你系统上使用那个版本的程序。（程序版本和系统有冲突。）
03. “Why do you want to do it that way?” 你怎么会想着那样操作啊？
02. “Where were you when the program blew up?” 程序崩溃时，你在做什么呢？（做了哪些操作？）

第1条会是什么？猜猜看吧！

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

01. “It works on my machine” 在我机器上好好的！！！（潜台词：怎么在你那就出问题了呢！！！）

1顶一下记得刚刚毕业的时候，自己连断点也不会打，当时还在用JCreate ，就连毕业设计也是用 System.out 找 Bug 的，想想真的很笨。开始工作后，一个星期过去了，在一个 1 、 2 百万行的系统中找 Bug ，我依然在用 System.out ，当时最痛苦的就是修改代码，每次找到疑似 Bug ，就输出一下，然后重启（那时也不知道代码热替换），直到有一天带我的导师发现了这样笨笨的调试 Bug ，才让我第一次认识...[阅读全文]

记得刚刚毕业的时候，自己连断点也不会打，当时还在用JCreate ，就连毕业设计也是用 System.out 找 Bug 的，想想真的很笨。开始工作后，一个星期过去了，在一个 1 、 2 百万行的系统中找 Bug ，我依然在用 System.out ，当时最痛苦的就是修改代码，每次找到疑似 Bug ，就输出一下，然后重启（那时也不知道代码热替换），直到有一天带我的导师发现了这样笨笨的调试 Bug ，才让我第一次认识了断点，也知道了代码修改完了可以进行热替换， 我这个中国教育的半牺牲品才算向美好生活迈进了一小步。

1、 条件断点
　　断点大家都比较熟悉，在Eclipse Java编辑区的行头双击就会得到一个断点，代码会运行到此处时停止。
条件断点，顾名思义就是一个有一定条件的断点，只有满足了用户设置的条件，代码才会在运行到断点处时停止。
在断点处点击鼠标右键，选择最后一个”Breakpoint Properties”

断点的属性界面及各个选项的意思如下图，

2、 变量断点
　　断点不仅能打在语句上，变量也可以接受断点，

　　上图就是一个变量的打的断点，在变量的值初始化，或是变量值改变时可以停止，当然变量断点上也是可以加条件的，和上面的介绍的条件断点的设置是一样的。
3、 方法断点
方法断点就是将断点打在方法的入口处，

　　方法断点的特别之处在于它可以打在 JDK的源码里，由于 JDK 在编译时去掉了调试信息，所以普通断点是不能打到里面的，但是方法断点却可以，可以通过这种方法查看方法的调用栈。
4、 改变变量值
　　代码停在了断点处，但是传过来的值不正确，如何修改一下变量值保证代码继续走正确的流程，或是说有一个异常分支老是进不去，能不能调试时改一下条件，看一下异常分支代码是否正确？
在Debug 视图的 Variables 小窗口中，我们可以看到 mDestJarName 变量的值为 ” F:\Study\eclipsepro\JarDir\jarHelp.jar ”

　　我们可以在变量上右键，选择”Change Value…” 在弹出的对话框中修改变量的值，

　　或是在下面的值查看窗口中修改，保用Ctr+S 保存后，变量值就会变成修改后的新值了。

5、 重新调试

这种调试的回退不是万能的，只能在当前线程的栈帧中回退，也就说最多只能退回到当前线程的调用的开始处。
回退时，请在需要回退的线程方法上点右键，选择 “Drop to Frame”

6、 远程调试
　　用于调试不在本机上的程序，有两种方式，
1、本机作为客户端
2、本机作为服务端
使用远程调试的前提是服务器端和客户端的代码是一致的。
本机作为客户端
　　本机作客户端比较常用，需要在远端的服务器上的java程序在启动时打开远程调试开关，
服务器端需要加上虚拟机参数
1.5以前版本（1.5以后也可用）：【-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8000 】
1.5及以上版本：【 -agentlib:jdwp=transport=dt_socket,server=y,address=8000】
F:\Study\eclipsepro\screensnap>java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8000 -jar screensnap3.jar
连接时远程服务器时，需要在Eclipse中新建一个远程调试程序

这里有一个小地方需注意，连接上的时候貌似不能自动切换到Debug视图，不要以为本机的调试程序没有连接到服务器端。
本机作为服务端
　　同本机作为客户端相比，只需要修改一下“Connection Type”

这时Eclipse会进入到等待连接的状态

　　连接程序使用如下参数即可连接本机服务器，IP地址请用实现IP替换~~
【-agentlib:jdwp=transport=dt_socket,suspend=y,address=127.0.0.1:8000】
F:\Study\eclipsepro\screensnap>java -agentlib:jdwp=transport=dt_socket,suspend=y,address=127.0.0.1:8000 -jar screensnap3.jar
远程调试时本地的代码修改可同步到远程，但不会写到远程的文件里，也就是说本地修改会在下次启动远程程序时就没有了，不会影响到下次使用时的远程代码。
7、异常断点
　　经常遇见一些异常，然后程序就退出来了，要找到异常发生的地方就比较难了，还好可以打一个异常断点，

　　上图中我们增加了一个NullPointException的异常断点，当异常发生时，代码会停在异常发生处，定位问题时应该比较有帮助。

2顶一下Java 7 GA 在前几天发布了，但是如Uwe Schindler 所述，HotSpot Loop optimizations存在一些非常可怕的默认启用的bug。最好的情况下，这些bug会导致JVM崩溃，最坏的情况下，会导致loops的不正确的执行。 除非，除非在你的Java代码里面不用任何的loops。 附 Uwe Schindler 的邮件： From: Uwe Schindler Date: Thu, 28 Jul 2011 23:13:36 +0200 Subject: [WARNING] Index corruption and ...[阅读全文]

Java 7 GA 在前几天发布了，但是如Uwe Schindler 所述，HotSpot Loop optimizations存在一些非常可怕的默认启用的bug。最好的情况下，这些bug会导致JVM崩溃，最坏的情况下，会导致loops的不正确的执行。

除非，除非在你的Java代码里面不用任何的loops。

附 Uwe Schindler 的邮件：

From: Uwe Schindler

Date: Thu, 28 Jul 2011 23:13:36 +0200

Subject: [WARNING] Index corruption and crashes in Apache Lucene Core / Apache Solr with Java 7

Hello Apache Lucene & Apache Solr users,

Hello users of other Java-based Apache projects,

Oracle released Java 7 today. Unfortunately it contains hotspot compiler

optimizations, which miscompile some loops. This can affect code of several

Apache projects. Sometimes JVMs only crash, but in several cases, results

calculated can be incorrect, leading to bugs in applications (see Hotspot

bugs 7070134 [1], 7044738 [2], 7068051 [3]).

Apache Lucene Core and Apache Solr are two Apache projects, which are

affected by these bugs, namely all versions released until today. Solr users

with the default configuration will have Java crashing with SIGSEGV as soon

as they start to index documents, as one affected part is the well-known

Porter stemmer (see LUCENE-3335 [4]). Other loops in Lucene may be

miscompiled, too, leading to index corruption (especially on Lucene trunk

with pulsing codec; other loops may be affected, too – LUCENE-3346 [5]).

These problems were detected only 5 days before the official Java 7 release,

so Oracle had no time to fix those bugs, affecting also many more

applications. In response to our questions, they proposed to include the

fixes into service release u2 (eventually into service release u1, see [6]).

This means you cannot use Apache Lucene/Solr with Java 7 releases before

Update 2! If you do, please don’t open bug reports, it is not the

committers’ fault! At least disable loop optimizations using the

-XX:-UseLoopPredicate JVM option to not risk index corruptions.

Please note: Also Java 6 users are affected, if they use one of those JVM

options, which are not enabled by default: -XX:+OptimizeStringConcat or

-XX:+AggressiveOpts

It is strongly recommended not to use any hotspot optimization switches in

any Java version without extensive testing!

In case you upgrade to Java 7, remember that you may have to reindex, as the

unicode version shipped with Java 7 changed and tokenization behaves

differently (e.g. lowercasing). For more information, read

JRE_VERSION_MIGRATION.txt in your distribution package!

On behalf of the Lucene project,

Uwe

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134

[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7044738

[3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068051

[4] https://issues.apache.org/jira/browse/LUCENE-3335

[5] https://issues.apache.org/jira/browse/LUCENE-3346

[6] http://s.apache.org/StQ