Java用于嵌入式系统的局限

相关推荐

Java用于嵌入式系统的局限

　　java语言的诸多优点在某些情况下恰恰可能成为其不利于在嵌入式系统中得以广泛应用的绊脚石。yjbys小编下面为你整理了关于Java用于嵌入式系统的局限，希望对你有所帮助。

　　局限1：性能较低

　　由于解释Java字节码比相当的C或C++写的程序运行起来要慢5到10倍，对一些并非受制于CPU的嵌入系统来说，这一性能缺点不是问题，但是更经常的较慢的速度会导致无法接受的应答时间。

　　解决方案

　　有几种可能的解决方案可缓解速度慢的问题。

　　使用更快、更强大的处理器，使系统响应时间缩小到可以接受的范围。不过这个方法将增加每个系统的成本。

　　使用母语Java编译器来获得比较好的性能。但这样做，就放弃了与Java平台无关的优点，好在大多数嵌入系统都只在一种平台上运行。

　　在系统上并入一个JIT编译器，这样Java类装入时就被编译。不过，如果为接纳JIT编译器而不得不增加额外的内存，这个方法也会增加系统成本。另外，若系统各部分是按需求逐渐添加，则应该控制程序装入的时机，以使在装入类进行编译时产生的暂停不会影响系统的响应时间。

　　局限2：垃圾收集的系统开销过大

　　Java中的自动内存分配和垃圾收集性能是很实惠的，但是，从实时系统的角度来看，它的问题恰好就在于它是自动的。当垃圾收集进行时，开发者对系统的控制就受限了。因为，垃圾收集运行时，它冻结了系统其余部分的处理。这是因为它必须要在内存中移动对象，并必须在程序再次运行前，更新所有引用(指向)那些对象的程序变量。垃圾收集需要冻结处理的时间，具体取决于内存量和处理器的速度。很显然，这对硬实时系统是无法接受的，甚至极端时对软实时系统也是成问题的。

　　解决方案

　　垃圾收集以三种方式开启。首先JVM有一个后台垃圾收集线程，此线程倾向于在它一看见系统有空闲就开始垃圾收集，若有事件想要唤醒另一个线程，后台垃圾收集就会被该线程占先，但它不会立刻被占先，它得更新那些已被移动的对象的所有引用后，才能让一个线程运行。其次，若JVM没找到足够内存来满足某个内存分配请求，它将启动一个不会被占先的垃圾收集，在该操作完成之前，系统的其余部分被禁止。最后，一个应用程序能通过调用Systev.gc()方法来启动垃圾收集。所以，如果知道系统暂时不会执行任何时序上关键的任务，就可以启动垃圾收集，避免稍后在更关键时段进行收集。

　　局限3：JVM的内存开销过大

　　前面我们也论述了许多 JVM的内置特点，比如图形和网络，它们使得Java程序更快上市。所有这些特点的负面是JVM的内存开销。因为JVM是一个整块(要达到Java的可移植的目的，必须完整的采纳)，JVM的内存占用量不能减少。现在的JVM最少需要2MB以上的内存。

　　解决方案

　　如果Java程序也在使用一些消耗内存的功能，由于一个JVM中有那么多的功能，各个Java应用程序就能写得小一点。如果建立的是一个从网络上动态下载并运行多个程序的系统，那么这将是个很大的优点。但Java仍然不具备可配置性和可伸缩性。

　　局限4：缺乏直接硬件接口能力

　　Java缺乏直接同硬件接口的能力。JVM仅仅是一个虚拟的机器，一个对硬件的软件抽象，虚拟机控制与实际硬件的接口，而我们只能和虚拟机打交道。

　　解决方案

　　但这并非是无法逾越的限制，很多C程序使用内嵌汇编来规避性能上的瓶颈，所以Java程序也能使用C来获得对硬件的直接访问。

　　让Java和C一起工作有两种方式。首先，可以使用本地方式，它们是用C/C++或另一种语言写的，但当调用时，则装入与JVM同样的内存空间，运行于同样的环境。因为它们被编译成机器码，本地方式运行更快并能直接访问硬件。本地过程与Java代码之间通过套接来彼此交流，就像网络中通信端点使用的套接一样。不过在选择了混合语言方法后，Java的与平台无关和安全特点就没有了。

　　另外，可以考虑将前面提到的Java处理器作为软件JVM的解释器部分作为一种硬件实现方案。Java程序能在这些处理器上直接运行并操纵硬件，要注意的是必需加一些特殊目的的指令给这种语言才能直接与处理器一起工作。

　　局限5：语言尚不够成熟

　　从标准的程序设计语言角度来看，Java还很年轻，也很粗糙。如果Java不是由一个小组开发的，也许某些错误和疏忽已经被发现和解决了。在Java亮相以后，它立即被用于比原来预期更多的地方。这一切都意味着Java最初的构思和实现，虽然坚实和有用，但在安全、大小和性能几方面仍感欠缺。

　　在其进一步发展中，Sun公司分了三个步骤来促进Java成为一种通用语言和计算机平台。首先，用Java编程实现现存的商业和企业的一些功能活动，诸如电子邮件、日历和字处理程序。其次，把Java提供给企业，使它成为一种编写内部应用程序的方法。最后一步，是为传统嵌入式设备应用，比如为移动电话、机顶盒以及打印机定义Java API以及语言功能。

　　由此可见，Java的嵌入式应用是排在Sun公司日程的最后的，Sun公司在继续为这些用途发展此语言，但对这方面的发展次于桌面及企业用途。按Sun公司的优先顺序，很可能还要过一段时间才能解决嵌入式应用中涉及到的一些问题。在此之前，嵌入式系统的编程人员可能不得不迂回、妥协以及使用第三方解决方案。

　　Java开发的编程工具也仍在发展之中。有几个厂家提供编译器和开发工具，如Symantec、Microsoft以及Sun公司。Sun不再是JVM和JIT的惟一供应商，其他几个供应商的产品也很有竞争力。Parasoft公司的Jtest软件自动为Java模块生成检测案例，而Numega公司的Jcheck为JVM中的程序行为提供一定的可见性。不过两者都只能处理调试程序中的一小部分，而且都是针对桌面系统开发设计的，虽然它们也能用于嵌入开发过程。

　　目前Java仍然没有交叉调试解决方案，即那种传统上被嵌入系统开发者用来处理目标平台上程序的方案，所以很可能必须用C/C++来写程序中针对硬件的部分。不管怎样，开发者最好用一个C/C++交互调试器来调试那些代码，并在目标系统上用弹出对话框，保持记录文件，或其他类技巧来调试Java.

【Java用于嵌入式系统的局限】相关文章：