Java Swing多线程死锁问题解析
Java Swing多线程死锁问题解析
在基于Java Swing进行图形界面开发的时候,经常遇到的就是Swing多线程问题。我们可以想想一下,如果需要在一个图形界面上显示很多数据,这些数据是经过长时间、复杂的查询和运算得到的。如果在图形界面的同一个线程中进行查询和运算工作则会导致一段时间界面处于死机状态,这会给用户带来不良的互动感受。为了解决这个问题,一般会单独启动一个线程进行运算和查询工作,并随时更新图形界面。这时候,另一个问题就出现了,可能不仅没有解决原来偶尔死机问题,还可能导致程序彻底死掉。幸运的是在JDK中暗藏了一个中断程序的快捷键,就是CTRL+BREAK,这个快捷键Sun并没有在文档中公布。如果在命令行模式下启动Java程序,然后按CTRL+BREAK键,会得到堆栈的跟踪信息。从这些跟踪信息中就可以知道具体引发死机的位置了。
当一个程序产生死锁的时候,你一定会希望尽快找到原因并且解决它。这时候,你一般的精力会用在查找引发死锁的位置,另一半的精力会用于对堆栈进行跟踪一确定引发死锁的原因。但是在Java Swing程序中,你的所有努力可能都是没有价值的。这是因为Java对Swing的多线程编程有一个特殊要求。就是在Swing里,只能在与Swing相同的线程里对GUI元件进行修改。
也就是说,如果你要执行类似于jLabel1.setText("blabla")代码,必须在Swing线程中,而不允许在其他线程当中。如果必须在其他线程中修改元件,可以使用类似一下方式解决:
SwingUtilities.invokeLater(new Runnable() {
public void run() {
jLabel1.setText("blabla");
}
}
invokeLater方法虽然表面有时间延迟执行含义,但是实际上几乎没有任何影响,可能在几毫秒之内就会被执行。另外还有一个invokeAndWait方法,除非特殊需要,否则几乎是不用的。
在不使用invokeLater的情况下,导致刷新问题是可以理解的,但是导致死锁就优点令人匪夷所思了。幸运的是,不是任何时候都需要调用改方法,这是因为大多数情况下,我们都是在与Swing同一个线程里进行界面更新。例如监听按钮点击事件的ActionListener.actionPerformed方法就是运行在与Swing相同的线程中的。但是如果在回调类中引用了另一个类,并且是不属于AWT/Swing的,那么结果就很难确定了。所以说使用invokeLater应该是最安全的。
相关文档:
在成功实现Java调用C++之后,接下来想到能否通过JNA实现Java调用Fortran,今天试验了一下,还是比较容易的。
网上有一个Java调用F95的例子,但是我考虑不仅要实现F95的调用,还要实现F77的调用,所以费了一些周折。
问题的关键在于F77为过程名自动添加了一个尾部的下划线,所以sub1这个过程,到Java一端,就变成了sub1_, ......
最近公司碰到需要用图表的形式显示一些数据,我就开始到网上查询,查到了jfreechart和amcharts,这两者我都实现过了,jfreechart最后生成图片,但是图片效果不是我想要的,然后又研究amcharts 它的效果确实很好,而且官方网站上还有好些例子可供下载,网址是:www.amcharts.com
(想要完成一个amcharts图形需要swfobjects. ......
栈与堆都是Java用来在Ram中存放数据的地方。与C++不同,Java自动管理栈和堆,程序员不能直接地设置栈或堆。
Java的堆是一个运行时数据区,类的对象从中分配空间。这些对象通过new、newarray、anewarray和multianewarray等指令建立,它们不需要程序代码来显式的释放。
......
最近在开发过程中发现一个问题:Boolean类型的值无法在flex和java间传递,经过一段研究发现,问题出现在Boolean类型的getter和setter方法上。
按照javabean的规范,小布尔类型的getter是以is做前缀的,但是大布尔类型的getter就成了以get为前缀了(大布尔作为引用类型,已经被视为普通 ......