。这极大地简化了应用程序中的错误处理代码,进而获得更好地错误处理效果和更坚实可靠的代码。
I)线程
大多数操作系统都给一个过程产生和管理多个线程的能力,这些线程彼此独立地完成不同地任务。但是,很少由程序语言提供对线程管理的直线支持,通常都需要直接调用操作系统功能。Java却相反,直接在语言提供了产生、管理和协调同步线程地功能。与Java的其他特点一样,该功能是必要的,因为设计者不敢确定底层的操作系统是否支持多线程。
开发者越来越多的在程序中使用线程,将其作为满足一个程序不能完成的,通常相互无关的一些任务的一种手段。由于Java对线程有内置语言支持,以Java创建多线程较之与其它语言更简单、更自然。
J)图形
JVM包括一个庞大的图形及窗口支持程序包,称为Abstract Windowing Toolkit(AWT)。用AWT,你能在应用程序中快速而轻易地创建精致而强大的图形用户界面。对于需要精细的用户界面的嵌入系统来说,AWT能节省大量开发时间,从而是产品更快的走向市场。
3、Java用于嵌入式系统的局限及解决方案
A)性能
如前所述、解释Java字节码比相当的C或C++写的程序运行起来要慢5到10倍。对一些并非受制于CPU的嵌入系统来说,这一个性能缺点不是问题,但是更经常的较慢的速度会导致无法接受的应答时间。有几种可能的解决方案可缓解速度慢的
问题。
1)使用更快、更强大的处理器,使系统响应时间缩小到可以接受的范围。这个方法将增加每个系统的成本。
2)使用母语Java编译器来获得比较好的性能。但这样做,你就放弃了与Java平台无关的优点,好在大多数嵌入系统都
只在一种平台上运行。
3)在你的系统上并入一个JIT编译器,这样Java类装入时就被编译。若你为接纳JIT编译器而不得不增加额外的内存,这个方法也会增加系统成本。另外,若你的系统各部分是按需求逐渐添加,你应控制程序装入的时机,以使在装入类进行编译时产生的暂停不会影响系统的响应时间。
B)垃圾收集的系统开销
前面论述过,Java中的自动内存分配和垃圾收集性能是实惠的,因为它去掉了最通常的程序错误根源并简化了程序设计人员的工作。但是,从实时系统的角度来看,它的问题恰好就在于它是自动的。当垃圾收集进行时,你的控制就受限了。
垃圾收集运行时,它冻结了系统其余部分的处理。这是因为它必须要在内存中移动对象,并必须在程序再次运行前,更新所有引用(指向)那些对象的程序变量。垃圾收集能冻结处理达数十分之一秒,具体取决于内存量和处理器的速度。很显然,这对硬实时系统是无法接受的,甚至极端时对软实时系统也是成问题的。
垃圾收集以三种方式开启。首先JVM有一个后台垃圾收集线程,此线程倾向于在它一看见系统有空闲就开始垃圾收集,若有事件想要唤醒另一个线程,后台垃圾收集就会被该线程占先,但它不会立刻被占先,它得更新那些已被移动得对象的所有引用后,才能让一个线程运行。
其次,若JVM没找到足够内存来满足某个内存分配请求,它将启动一个不会被占先的垃圾收集,在该操作完成之前,系统的其余部分被禁止。
最后,一个应用程序能通过调用Systev.gc()方法来启动垃圾收集。所有,如果你知道系统暂时不会执行任何时序上关键的任务,你可以启动垃圾收集,并希望避免稍后在更关键时段进行收集。
C) JVM的系统开销
我们已经论述了许多JVM的内置特点,比如图形和网络,它们使得你的Java程序更快上市。所有这些特点的负面是JVM的内存开销。因为JVM是一个整块(要达到Java的可移植的目的,你必须完整的采纳),JVM的内存占用量不能减少。现在的JVM最少需要2MB以上的内存。
但是如果你的Java程序也在使用一些消耗内存的功能,由于一个JVM中有那么多的功能,各个Java应用程序就能写的小一点。如果你建立的是一个从网络上动态下载并运行多个程序的系统,那么这将是个很大的优点。但Java仍然不具备可配置性和可伸缩性,而这些是嵌入操作系统一直以老字号自居的特点。