用于嵌入设备的JAVA应用程序管理程序.pdf

用于嵌入设备的JAVA应用程序管理程序
    在嵌入设备环境中，在设备上常安装一个与硬件无关的处理机例如Java虚拟机，以便允许下载程序和在设备上执行。这样一个系统允许一个以与硬件无关的语言例如Sun Micro Systems Java编写的程序下载到任何硬件支持Java环境，以便为一特殊用途定制它。这个定制常被称为设备的“个性”。多个应用程序可以在一个嵌入设备一齐被运行，以便确定该设备的个性。用这种方法可以使设备动态地以不同的独特方式起作用。例如，一个嵌入设备如一台冰箱可以被定制为自动地跟踪其内容。就象食物类型和同类食物的命名习惯可能随文化背景不同而异一样，嵌入设备冰箱可能通过下载一个描述食物类型和命名习惯的新的个性到Java使能嵌入冰箱设备来定制用户的特定文化。

    在嵌入设备域中，在设备上安装一个与硬件无关的处理机例如Java虚拟机，以便允许下载应用程序和在设备上执行。Java语言提供建造动态地装载新程序的程序的基本功能。然而，Java语言不提供程序的装入程序的实现，也没有能力在装载后管理程序。Java语言也不提供在存储器受限制的嵌入设备内下载和管理应用程序的工具。

    几种现有的Java技术支持程序的装入程序类型地功能。SunMicrosystem’s Servlet API允许一个Java使能Web服务器动态地扩充服务器的能力。Servlet API主要被创建来替代Web服务器中典型的CGI功能。Servlets较之CGI类型程序的优点包括与平台无关、复用性(通过面向目标技术重复使用Java类的能力)、性能效率(Servlet的可配置的启动方式，其允许相同的Servlet实例处理许多请求)(与为每个至CGI原来的调用创建一个新进程相反))和管理效率(基于Web服务器的Sun’s Java提供一个Java管理小应用程序，其很容易管理增添的新Servlet类，以及启动和停止Servlets)。

    Servlet API通过委托所有Servlets实现三个方法：init()、Service()和destroy()来规定一个Servlet的生存日期。当Servlet第一次被调用时，调用init()方法；Service()方法被调用来处理来自一个客户的每个请求；以及当Serlet被停止(即Web服务器关闭)时调用destroy()。Servlet API不直接支持存储器管理或提供一个管理Servlets的公共包。

    HP公司的Embedded Java Lab SmallWeb提供一个在JVM中执行的至基于Java目标的基于Web的接口。SmallWeb当需要时可以装载目标，同时对目标提供一个把它们的功能(通过方法调用)转出到Web浏览器的装置。SmallWeb不直接提供停止应用程序目标或存储器管理特性。此外，SmallWeb通常要求一个文件系统，同时对某些嵌入环境，SmallWeb的辅助操作要求可能太大。

    在许多嵌入领域中使用Java的一个问题是Java存储器子系统的非确定的方面。Java语言的非确定存储器管理方案允许通过一个垃圾回收站方法gc()回收未引用目标；然而，垃圾回收站没有规定如何或何时回收这些目标。原来的应用程序一般通过调用JavaRuntime类gc()方法来使垃圾回收站出现。如果JVM运行存储器溢出，则出现一个OutofMemory.Error错误。虽然不必管理存储器是Java语言的一个优点，但大多数嵌入应用程序需要在如何管理存储器方面较之在Java语言中目前提供的更严格的控制。需要更严格的控制是因为有些嵌入应用程序必须继续在低存储器环境中执行。这一般通过在原来的非Java嵌入应用程序中补充一个存储器管理程序来解决，以确保为了继续执行有足够存储器仍是可用的。

    因此，为了下载到Java使能嵌入设备中和控制在Java使能嵌入设备中的应用程序的寿命，对通用方法存在一个需求。对一个存储器管理处理程序也存在一个要求，存储器管理处理程序处理在设备上执行应用程序期间检测到的低存储器或没有存储器的情况，同时该处理程序按照基于优先的算法释放存储器。

    本发明是一个新颖的系统和方法，用于管理在存储器受限制的嵌入设备环境中应用程序的下载和生存周期。一个基于Java的应用程序管理程序控制在嵌入设备上安装的单个Java虚拟机(JVM-JavaVirtual Machine)内运行的Java应用程序的下载、执行和高速缓存器。一个有网络能力的应用程序接口(API-Application ProgramInterface)被规定，它提供装载类文件、启动、初始化和停止应用程序执行的功能，以及在Java使能嵌入设备中存储器管理的功能。本发明使嵌入设备能方便地重新编程以及单独管理嵌入设备使用的硬件类型。

    根据阅读下面的详细描述并结合附图将会更好地理解本发明，在附图中，同样的参考标志被用来标记相同的元件，其中附图如下所示：

    图1是本发明工作的网络系统的系统图；

    图2是本发明所实现的嵌入设备的方块图；

    图3是说明应用程序如何完成生命的流程图；

    图4是按照本发明实现的一个应用程序管理程序的一个实施例的工作流程图；

    图5是按照本发明实现的一个应用程序管理程序的一个实现的类图；

    图6是说明为执行一个装载操作在图5所示的类之间通信的流程图；

    图7是说明为执行一个启动操作在图5所示的类之间通信的流程图；

    图8是说明为执行一个停止操作在图5所示的类之间通信的流程图；以及

    图9是说明为处理一个存储器溢出状态在图5所示的类之间通信的流程图。

    下面详述嵌入设备的一种新颖的应用程序管理程序。虽然本发明从Java环境的角度加以描述，但业内专业人士将会懂得，本发明的原理适用于由处理以与硬件无关的语言编写的代码的一个与硬件无关的处理器组成的任何系统。

    现在回到图1，其中示出一个网络系统10，其包含一个经由网络14与一嵌入设备20通讯的计算机系统12。网络14可以是普通的陆上连接的有线网络如LAN(局域网)或WAN(广域网)，或者可以是一个无线网络，或者它们的任何组合。

    计算机系统12在这个系统中用作为一个客户，执行一个客户应用程序2，其经由一个客户接口4通过网络14与服务器设备(例如，嵌入设备20)相连。在这个例子中，客户应用程序又发送请求(例如，下载Appl3，启动Appl3，停止Appl2)到嵌入设备20，其用作一个服务器以便服务该请求。客户应用程序2可以在计算机系统12上它自己的环境中执行，或者用另一个办法在一个Java使能Web浏览器(未示出)内执行，该浏览器包含它自己的Java虚拟机(JVM-JavaVirtual Machine)(未示出)。Web浏览器用嵌入的Java小应用程序解释Web文件，Java小应用程序规定主客户应用程序小应用程序类文件的地点。Web浏览器启动它的JVM并传送客户应用程序小应用程序类文件的地点到它自己的类装入程序6。每个类文件知道它请求的任何附加的类文件的名字。这些附加的类文件可以来自于网络14(即与网络14相连的其它机器)或客户计算机系统12。

    嵌入设备20是一个Java使能设备，具有安装在它上面的Java虚拟机(JVM)22。图2是更详细说明嵌入设备的一个方块图。嵌入设备20包括一个JVM22、一个由应用程序高速缓存器52和数据高速缓存器54组成的存储器50以及一个网络接口25。JVM22包括一个类装入程序42和一个执行单元46。最好JVM22也包括一个字节代码检验器44，虽然在有些存储器受限制的设备中这不可能实现。按照本发明，类装入程序42采用本发明的应用程序管理程序24来实现。应用程序管理程序24是一个负责下载、执行和高速缓存器其它基于Java的程序的Java程序。当JVM22开始在嵌入设备20上执行时，它开始执行应用程序管理程序24。

    应用程序管理程序24是一个服务器设备，用作一个基于网络的类装入程序，能通过网络14经由一个网络协议48接收应用程序类文件40，并把在应用程序类文件40中包含的应用程序类传到文件中。如本专业技术人员所知，一个类文件40是包括与硬件体系结构无关的由Java编译程序产生的字节代码的一个文件。字节代码仅由JVM例如JVM22才可执行。应用程序管理程序24是一个非典型的基于网络的Classloader，根据需要从网络14装载类40。不是象由典型类装入程序通常所做的那样通过Javaload Class()方法装载类文件40，应用程序管理程序24代之以在服务器套接字或其它协议48上等待下载类文件40的一个请求。当接收到一个下载请求时，应用程序管理程序24从网络14接收类文件40，把它传到类28a、28b，然后调用JavaClassLoader.define class()方法。类28a、28b应被解析以确保通过调用JavaClass Loader、resolve Class()方法它准备好用于目标实例。

    图3说明应用程序26a、26b、26c如何带来生命力。如图所示，这通过例示一个应用程序的Java类28a、28b，创建类28a、28b的一个实例目标30a、30b、30c，然后调用在目标30a、30b、30c上的一个main方法以运行应用程序26a、26b、26c来完成。相同应用程序的多个实例可以通过创建相同Java类的多个实例同时被执行。例如，如图3所示，目标30a和30b是相同类28a的实例，而目标30c是不同类28b的一个实例。因此，应用程序26a和26b是相同应用程序的不同实例，其可以同时运行，而应用程序26c是一个完全不同的应用程序。

    应用程序管理程序24提供下载、启动、停止、查询和存储器管理能力。为了通过网络14提供这些能力，嵌入设备20包括一个实现网络协议48的网络接口25，其允许客户12发送请求到嵌入设备20的应用程序管理程序24。在优选实施例中，网络接口25使用由应用程序管理程序24规定的一种通用Java语言应用程序接口(API)对应用程序管理程序24说话。通用API给远程设备例如计算机系统12提供规定设备20的所希望的管理的能力。附录A列出在本发明示例性实施例中定义的APIs。

    特别是，应用程序管理程序24允许新应用程序通过网络14下载到设备20。在优选实施例中，这经由API的loadApplClass()方法来实现。loadApplClass()方法处理Java类文件40的下载和检验，把在类文件40中包含的应用程序类28a、28b装载到设备20上的Java环境，以及准备通过采用一个Java解释程序或一个Just in Time(JIT)编译程序(未示出)例示应用程序目标30a、30b、30c来执行的类28a、28b。应用程序管理程序24也管理在嵌入设备20上的Java应用程序26a、26b、26c的启动和停止，以便允许在计算机系统12或其它连网设备上的一个用户控制在嵌入设备20上所装载的Java应用程序26a、26b、26c的执行。在优选实施例中，这经由通用API的StartAppl()方法和stopAppl()方法来完成。应用程序管理程序24也允许查询应用程序信息例如哪个类目标28a、28b目前被装载，哪个类具有应用程序实例30a、30b、30c，以及每个应用程序实例处于什么执行状态(例如；“初始化”、“执行”、“停止”)。这在优选实施例中分别经由方法applClasses( )、applications()和appllnstances()来完成。每个被装载的类目标28a、28b的名字在应用程序管理程序24目标内被作为一个属性，最好作为一个散列表被保存在一个应用程序列表23中。应用程序管理程序24也允许从Java环境中查询信息，例如可用存储器数量和总存储器数量。在优选实施例中，这个信息采用freeMemory()方法和totalMemory()方法来查询。应用程序管理程序24也提供存储器管理能力，包括在一个已装载应用程序必须被卸载之前设置所要求的空闲存储器数量的范围的能力，以及设置卸载已高速缓存器的应用程序的次序的能力。这在优选实施例中采用SetFreeMemoryLimit()和SetFreeAppsFirst()方法来完成。空闲存储器范围和卸载应用程序的次序可以采用getFreeMemoryLimit()和getFreeAppsFirstPolicy()方法来查询。这个信息保存在应用程序管理程序24目标内的一个散列表中，无论是作为每个应用程序列表23入口的一个单独字段，或是作为一个单独的卸载优先权列表21。

    网络协议48被用作提供经由网络接口25对应用程序管理程序24的网络访问。网络协议48可以按照几种可供选择的实施例中的任何一种来实现。

    在第一个实施例中，网络协议48采用Java远程方法支持(RMI)实现Java RMI允许在驻留在其它JVMs中的目标上进行直接方法调用。RMI一般要求大量存储器以支持目标连续、识别和方法发送。如果嵌入设备支持运行RMI的高存储器辅助操作，包括支持RMI名字服务器的运行，那么RMI是一个好的实现选择，如果与嵌入设备20相互作用的客户应用程序和应用程序管理程序24是基于Java的话。其它分布式目标机理(例如CORBA、DCOM)与RMI之间确实存在桥梁，同样允许客户以其它语言编写。使用RMI，应用程序管理程序24可以接受来自远程客户12的直接调用，以装载、启动和管理应用程序26a、26b、26c。基于RMI的应用程序管理程序接口的一个简单例子在附录B中给出。

    在第二个可供选择的实施例中，网络协议48采用网络套接字(例如TCP/IP套接字协议)实现。如果在客户12侧也使用Java，那么把协议48包装在一个Java类(或多个类)内是有利的，以确保协议48在客户12侧和服务器(嵌入设备20)侧保持一致。为了确保网络协议48不执行由客户12或应用程序管理程序24可能拖延引起的网络的阻塞阅读，最好经由JavaSocket.setSoTimeout()方法或通过使用JavaInputStream.available()方法对read()操作设置一个等待超时，以确定多少数据可以无阻塞地阅读。

    在这样一个网络套接字协议方案的一个实现中，识别所调用方法的单个字节，后面跟着由包装程序为那个特定方法译码的附加数据被传送。例如，要下载一个类文件40，客户12传送一个‘D’字符字节以表示该请求是为下载，后面跟着被传送的总数据长度，后面再跟着嵌入设备20的网络地址。在另一个实施例中，实际的数据是一个零终止字符类名字，后面跟着一个表示该类是否包括一个main方法的字节，后面再跟着包含类数据的字节。一个支持虚拟译码方法的目标模型被创建以执行协议译码。返回方法调用结果到客户12也可以在所使用的类似协议情况下被包装，以这一方法，结果被异步地从请求被返回，同时客户12实际上可以用作结果的一个网络服务器。如果客户12仅与一个嵌入JVM22交谈，同时是空闲地等待结果，那么可以采用一个较简单的方案，其中客户12等待(在一个超时情况下)结果同步地返回来。

    在优选实施例中，应用程序管理程序被作为一个Java网络服务器应用程序来实现，其接受编码成一个应用程序协议48的请求，例如Java远程方法支持(RMI)协议、Web主机请求的超级文本传送协议(HTTP)，或在TCP/IP套接字上的一个应用程序级协议。如前所述，在协议48中一个请求类型是一个应用程序的Java类文件40的下载。在优选实施例中，类文件40的下载通过调用方法loadApplClass()或方法loadAndlnit()实现。如前所述，类文件40是由JVM22使用的一个二进制Java字节代码流，以创建一个Java类目标30a、30b、30c。除了下载应用程序类文件40到存储器50外，应用程序26a、26b、26c继承的任何基(base)类或具有在类文件40中包含的应用程序类28a、28b的接口也被下载到存储器50中的一个应用程序高速缓存器52中。因为应用程序管理程序24允许在存储器50中的类文件40的高速缓存器，所以应用程序协议48允许经由跟随一个startAppl()方法调用的方法initAppl()执行驻留在存储器50中的已被下载的类文件。一旦一个类文件40被下载，JavaClassLoaderAPI就被用于例示与类文件40有关的类目标28a、28b。ClassLoader.defineClass()方法从类文件字节数组中建立一个类目标28a、28b。一旦被定义，该类必须被解析以执行类链接，其允许实例目标创建和方法调用。解析进程通过调用JavaClassLoader.resolveClass()API被初始化。

    一旦一个类28a、28b被装载和定义，类28a、28b的一个实例目标30a、30b、30c被创建，在示例性实施例中通过JavaClass.newlnstance()API创建。需要目标30a、30b、30c，以便调用所希望的方法启动应用程序26a、26b、26c。为了调用newInstance()，类28a、28b必须有一个缺省的设计函数，其没有自变量。

    应用程序26a、26b、26c通过调用在前面创建的目标30a、30b、30c上所希望的方法，传递任何自变量到该方法来执行。应用程序管理程序24必须知道访问目标的方法和传递什么自变量(如果有的话)。这可以用几种方法中的一种来完成。

    在一个实施例中，要求所有应用程序以便实现规定所调用的方法的一个Java接口。下面示出一个简单接口。

    公共接口ApplBase

    {

    公共空主线(InetAddress O)；

    }

    这个接口规定一个实例方法“main()”，其是当一个应用程序26a、26b、26c执行时被调用的第一个方法。因为它是一个实例方法，所以在执行main()之前必须由应用程序管理程序24创建类28a、28b的一个目标30a、30b、30c。这个目标在应用程序管理程序24中可以是一个JavaApplBase目标，因为仅仅main()被调用。在这个例子中，main()方法接收一个lnetAddress自变量，其包含下载类的客户12的网络地址。以这个方法，如果需要的话，应用程序可以通过一已知端口返回去与客户12通讯。

    在另一个实施例中，如果JVM22支持反射，例如通过JavaRMI。那么方法名字被下载到应用程序管理程序24以及反射被用来搜索所希望方法的应用程序类。一旦类28a、28b被装载，则JavagetDeclaredMethod()被调用在该类上以便查找所希望的方法。getDeclaredMethod()返回一个Method目标，其可以通用调用invoke()依次被用于执行该方法。

    在还有一个实施例中，从所有应用程序都从中继承的一个公共基类扩充的一个方法被调用。

    一旦执行之后，应用程序管理程序24记录应用程序26a、26b、26c的新运行状态。每个应用程序类28a、28b包括一个各自的实例列表29a、29b，其识别它的类存在的每个实例。在实例列表29a、29b中每个入口包括一个执行状态变量，它在实例应用程序26a、26b、26c的生存周期内由应用程序管理程序24更新。

    应用程序管理程序24处理在应用程序26a、26b、26c中产生的所有Java异常或错误，其要不然会引起JVM22终止。在应用程序终止情况下，应用程序管理程序24记录应用程序26a、26b、26c不再在运行(通过更新相应于在实例列表29a、29b中所识别的实例的执行状态)，同时如果类28a、28b没有被高速缓存器到存储器50，则让类目标28a、28b作为垃圾被回收。

    类28a、28b的高速缓存器是本发明的一个独特的特性，它便于获得更好的性能。每一次一个应用程序26a、26b被执行时不是下载应用程序类，而是应用程序管理程序24最好按照缺省高速缓存器类目标28a、28b，同时只有当明显地请求使用unloadAppl()方法或只有当存储器管理处理程序27由于低存储器或无存储器状态选择类被卸载时才卸载类28a、28b。在优选实施例中，当前已装载的类由存储器管理处理程序27卸载的次序采用SetFreeAppsFirst()方法设置。setFreeAppsFirst()方法允许客户在低存储器或无存储器状态中设置或更改应用程序被卸载的次序。这可以用几种方法中的任何一种来完成，包括通过在应用程序列表中增添一个卸载优先权字段到每个入口，它表示卸载类用的应用程序的顺序。通过高速缓存器类，应用程序管理程序24对该类保留一个标记，因而使Java虚所机22不会当垃圾回收28a、28b。应用程序类28a、28b则可以被重新使用以便创建类28a、28b的新实例30a、30b、30c，同时重新执行应用程序功能度。

    应用程序管理程序24最好也允许将应用程序数据高速缓存器到存储器50中的数据高速缓存器54中，甚至在一个应用程序已终止和/或被卸载之后也是如此。一个例子是在电子试验域中的Java应用程序。应用程序的第一次执行应保存安装信息，这使得该应用程序将来运行时能较快地执行。在这个例子中，应用程序管理程序24能高速缓存器试验系统校准信息。另外，通过高速缓存器试验系统校准信息进数据高速缓存器54，应用程序管理程序54保留对一个数据的标记，因而使Java虚拟机不会当垃圾回收数据。因此，以这个方式的数据高速缓存器允许信息被保存以供同一应用程序或不同应用程序下次运行用。

    应用程序管理程序24企图让应用程序26a、26b、26c能继续在低存储器或无存储器状态下执行。如果在应用程序26a、26b、26c执行期间JVM22运行存储器溢出，则产生OutOfMemoryError错误。应用程序管理程序24包括一个存储器管理处理程序27。它处理低存储器或无存储器状态。在优选实施例中，存储器管理处理程序27通过由JVM22产生的OutOfMemoryError的出现被触发进入运行。在一个实施例中，存储器管理处理程序27通过来自它的应用程序高速缓存器的明智地转储类目标28a、28b和应用程序目标30a、30b和30c来起反应。卸载被高速缓存器的类目标28a、28b和应用程序目标30a、30b和30c的次序采用setFreeAppsFirst()方法设置。另一方面，该次序按照在存储器管理处理程序27本身内被编码的一个预定算法来确定。通过调用JavaRuntime.gc()方法，应用程序管理程序通知JVM22卸载的类目标28a、28b和应用程序目标30a、30b和30c是可以用来被回收。来自应用程序高速缓存器52的类目标28a、28b的卸载迫使与类28a、28b有关的应用程序目标30a、30b和30c被终止以及同样被卸载。因此，如果应用程序执行的启动速度是重要的话，那么可能最好是在卸载类目标28a、28b之前卸载应用程序目标30a、30b和30c。另一方面，如果保持一个特定的应用程序无论如何总运行是重要的，那么可能最好是与那些目标有关的类一道卸载另一个类的所有应用程序目标，以便释放足够的存储器来保持该特定应用程序运行。让应用程序终止的解决办法是单独监视对低存储器状态起反应的存储器水平，或到检验点应用程序结果允许在一个检验点之后继续重新启动应用程序。这些方法可以允许执行应用程序使之继续不间断，或至少尽可能地接近不间断。

    应用程序管理程序24最好提供存储器管理功能度。在一个实施例中，应用程序管理程序24标记类目标28a、28b，应用程序目标30a、30b以及在各自的应用程序52和数据54高速缓存器中的全局数据，因而确保它们有关的目标不会被当作垃圾回收。

    在另一个实施例中，存储器管理处理程序27不断地监视空闲存储器水平，同时在低存储器或无有用存储器场合，从它的高速缓存器52、54中删除目标并启动垃圾回收站以便释放如所需要的那样更多的存储器。如前所述，在从应用程序高速缓存器52或数据高速缓存器54中删除入口之后，通过调用JavaRuntime.ge()方法启动垃圾回收站。关于应用程序管理程序24如何在低存储器状态管理存储器50，在实现一个应用程序管理程序24时必须进行选择。一个选择是哪个高速缓存器，应用程序高速缓存器52或是数据高速缓存器54，具有当低有用存储器产生时首先从中被删除的入口。在大多数情况下，它可能很容易删除应用程序目标和30a、30b、30c和有关的类目标28a、28b，同时当需要时重新下载它们。这个决定在它可以使用的长时间内被预测，以重新创建全局数据。

    应用程序和全局数据目标最好被设计成尽可能地独立，以使高速缓存器方案能正确地工作。如果一个全局数据类被标记为类目标28a、28b的一个成员，则未被标记的数据类对释放存储器毫无作为，除非类目标28a、28b也未被标记。一个标记为类目标28a、28b的全局数据类的相反情况也引起相同结果。类目标28a、28b应仅标记为在方法中，而不是在类成员中的全局数据类。最好全局数据目标决不标记为类目标28a、28b。

    图4是说明应用程序类高速缓存器52的管理的一个示例性实施例的工作流程图。应用程序管理程序24接收402来自一个客户12的请求。如果该请求的执行导致有用存储器的使用(例如，loadAppl()、loadAndlnit()、lniAppl())，则对于所接收请求的执行是否会导致一个低存储器或无存储器状态作出一个决定404。如果是的话，类目标28a、28b和/或应用程序目标30a、30b、30c被选择406，以便从应用程序高速缓存器52中卸载。所选的目标则从应用程序高速缓存器42中被卸载408。如果所接收的请求是一个loadAppl()或ladAndlnitAppl()请求，则一个类目标从网络14被装载和被定义410。如果请求是一个loadApp()请求，则该请求被完成。如果请求是一个loadAndlnitAppl()请求或一个lnitAppl()请求，则应用程序目标30a、30b、30c被例示412同时请求被完成。如果请求是一个startAppl()请求，则应用程序被启动414，一般通过调用在应用程序目标30a、30b、30c上的一个main()方法来实现。如果请求是一个stopAppl()请求，则应用程序被停止416。如果请求是一个unload()请求，则类目标28a、28b被卸载418。如果请求是一setFreeMemoryLimit()请求，则作为低存储器状态依据的空闲存储器阈值被设置420。如果请求是一个setFreeAppsFirst()请求，则为了在检测到低存储器或无存储器状态时卸载，选择应用程序类28a、28b和目标类30a、30b、30c的次序被设置422。如果请求是一个查询(例如，哪个应用程序类被装载(applClasses())，哪个应用程序被初始化(applications())，哪个应用程序目前正在运行(appllnstances())，存在多少可用存储器(freeMemory())，存在多少总存储器(totalMemory())，已存在的空闲存储器范围阈值是什么(getFreeMemoryLimit())，或已存在的卸载类和应用程序目标的次序是什么(getFreeAppsFirstPolicy())，则查询被执行，返回被请求参数424。

    当已确定404一个低存储器或无存储器状态存在时，在示例性实施例中应用程序管理程序24删除被选择为卸载的目标的标记，并通过调用javaRuntime.gc()方法使得未标记目标从应用程序高速缓存器52中被删除。如前所述，仅仅未标记的类28a、28b被从高速缓存器52中删除，因为只有未标记的类可以通过JavaRuntime.gc()方法作为垃圾被回收。在有些JVM22实现中，类的ClassLoader目标可能也必须是未被标记为当作垃圾被回收的类。

    图5是说明采用本发明的一个系统500的一个示例实现的一个类图。在图5的示例实现中所定义和使用的每个类的说明示于下面表1中。表2包含在图5的示例实现中所使用的每个类中所定义的主要属性的说明。如在图5中所示，类ApplMgr502管理应用程序类的一对多实例510。类ApplMgr502使用一个ServerProtocol类504，其与ClientProtocol类506交谈，以便与一个客户类ApplClient相连通。如在表1中所示，类ApplMgr502是实现应用程序管理程序24的类。应用程序类510模拟一个单一应用程序。ServerProtocol类504和ClientProtocol类506实现客户接口4。同时它们包装在应用程序管理程序类ApplMgr502和客户类ApplClient508之问的网络协议48。表1类说明ApplMgr总的应用程序管理程序类Application建造一个单一应用程序ServerprotocolClientprotocol包装在代表由ApplMgr支持的接口的ApplMgr和Applelint类之间的网络协议ApplBase定义方法的接口，一个应用程序必须定义为由ApplMgr所使用ApplClient示例客户侧应用程序，用于与ApplMgr类相互作用表2名字类别说明ApplMgr．idata属性全局数据值的散列表，它必须持续得超出应用程序类的寿命．通过get和set方法访问。ApplMgr.iappls属性应用程序目标集，其已告诉ApplMgr来管理。Application.icasses属性与这个应用程序有关的类的散列表。类用名字唯一地标识。一个类层次可以被用于创建一个应用程序，它要求使用一个散列表。Application.iappls属性当前执行的应用程序的实例集。实例用类名标识，对所创建的每个实例，实例计数器增1。Application.imainClass属性包含被执行的main()子程序的类。被执行的应用程序目标从这个类中被创建。ServerProtocol.isock属性用于与ApplMgr通讯的ServerSocket。ServerProtocol.iapplmgr属性ServerProtocol译码任何请求，然后在ApplMgr上进行适当的调用以便处理请求。ServerProtocol另一方面可以用直接RMI调用到ApplMgr来替代。ClientProtocol.isok属性ClientProtocol与ServerProtocol通讯用的套接字

    图6是说明类之间的通讯以完成一个新类的装载的系统500的方块图。表3规定初始假设、装载操作的结果和为完成装载所要求的代理程序。如所描述的那样，假设一个应用程序管理程序类ApplMgr 502正在嵌入设备20的JVM22中运行，同时通过指令ApplClient 508在客户计算机12上运行以便把新类下载到嵌入设备20，一个用户已请求一个下载。

                         表3    假设ApplMgr已经正在JVM中运行。    结果与应用程序有关的类被装载到JVM，“main类”的一个实例被创建，同时在这个新实例上init()方法被访问。    代理程序Dser＝指令ApplClient下载新应用程序类到运行ApplMgr的嵌入设备ApplClient＝下载Appl类的主机侧程序ClientProtocol＝处理客户的网络通讯的主机侧类ServerProtocol＝处理ApplMgr的网络通讯的服务器侧类ApplMgr＝应用程序管理程序类Application＝模拟一个被下载的应用程序的应用程序类

    如图6中所示，一个下载操作用从一个客户用户应用程序例如客户用户类ApplclientU 516至客户应用程序ApplClient 508的一个用户请求602开始。在这个例子中，客户用户类ApplclientU516通过遵照先传送一个‘D’字符，后跟包含类数据的文件名，再后跟类数据所要传送抵达的网络结点的协议产生一个下载请求。在这个例子中，类数据起名为‘test’，嵌入设备20的网络结点地址起名为‘HP’。请求602使得Applclient 508被运行以便下载类‘test’到结点‘HP’。Applclient508读出在‘test’中所包含的类数据到存储器中，然后调用Client Protocol.Load Class()方法604下载该类。ClientProtocol 506形成一个至结点‘HP’的ServerProtocol的网络14连接，同时经由网络14发送606与类数据文件‘test’有关的类数据。ServerProtocol 504译码该请求和类数据，然后调用ApplMgr.loadClass()方法608装载类。如果需的话(即类已经不被高速缓存器在应用程序高速缓存器中)，ApplMgr 502创建用于该类的一个应用程序目标610。ApplMgr502则调用在应用程序510上的loadClass()方法612，传送与类‘test’有关的所有类数据。新应用程序目标被添加616到应用程序的ApplMgr高速缓存器，应用程序列表ApplMgr.iapps23被更新616以反映类‘test’添加到它管理的它们应用程序目标的事实。如果被装载的类‘test’是一个main类，则应用程序定义和解析该类，创建该类的一个实例，同时调用实例的init()方法，618。一个真正的结果被传送620回到Applclient通知成功地装载类。

    在实现中，如果希望的话，ServerProtocol类504可以创建处理每个请求的一个单独的线索表，让多个请求同时被处理。如果以这个方式实现，由类ApplMgr502和Application510实现的方法必须适当地被同步。

    如果一个应用程序510被配制为多个类，则对每个类将进行一个loadClass()请求。这要求ApplMgr502能查找并添加类到一个已存在的应用程序目标510。应用程序用一个唯一的名字，与main类相同的名字来识别。按照惯例，在装载main类之前先装载base类和接口，以确保main类的实例被正确地创建。另一个方案是创建一个新ApplMgr方法以创建一个应用程序的一个实例。这使得相同类的多个应用程序能同时被执行。

    图7是说明为执行一个应用程序的启动在类之间的通讯的系统500的一个方块图。表4规定初始假设、启动操作的结果和为执行启动所要求的代理程序。如所描述的那样，假设一个应用程序管理程序类ApplMgr正在嵌入设备20的JVM22中运行，同时通过指令ApplClient在用户的机器上运行来启动嵌入设备20上的应用程序，一个用户已请求一个启动。

                             表4假设ApplMgr已经在JVM中运行。应用程序类以前已由ApplMgr装载结果所希望的应用程序开始执行代理程序Vser＝指令ApplClient在结点‘HP’上启动应用程序‘test’。Applclient＝启动应用程序的主机侧程序ClientProtocol＝处理客户的网络通讯的主机侧类ServerProtocol＝处理ApplMgr网络通讯的服务器侧类AppMgr＝应用程序管理程序类Application＝模拟被启动应用程序的应用程序类ApplBase＝被启动的应用程序实例

    如图7中所示，一个启动操作用从一个客户用户应用程序例如客户用户类ApplClientu 516至客户应用程序Applclient 508的一个用户请求702来开始。在这个例子中，客户用户类ApplClientu 516通过遵照先传送一个‘B’字符(为‘begin’)，后面跟应用程序名‘test’，再后面跟类数据要传送抵达的网络结点‘HP’的协议产生一个启动请求。请求702使得ApplClient 508被运行以便启动在结点 ‘HP’上的应用程序‘test’。ApplClient 508调用ClientProtocol.StartAppl()方法704启动应用程序。ClientProtocol 506形成一个至结点上的ServerProtocol 504的网络连接，同时发送706一个启动消息。ServerProtocol 504译码启动请求，然后调用ApplMgr.StarAppl()方法708。ApplMgr 502查出正确的应用程序目标510，然后调用710在应用程序510上的startAppl()方法。应用程序目标510创建712一个新线索表518以便执行714它自己的run()方法。在run()方法内，ApplBase实例514的main方法被调用716，传递任何参数。如果没有参数被传递到应用程序实例，则run()方法应被直接调用。应用程序目标510则更改718应用程序实例的状态以便执行。

    在另一个实施例中，一个ApplClass目标(即一个类装入程序512)管理模拟应用程序类510的一个实例的应用程序类。

    图8是说明为执行一个应用程序的停止在类之间通讯的系统500的方块图。表5规定初始假设、停止操作的结果和执行停止所要求的代理程序。如所描述的那样，假设一个应用程序管理程序类ApplMgr正在嵌入设备20的JVM22中运行，同时通过指令ApplClient在用户的机器上运行来停止嵌入设备20上的应用程序，一个用户已请求一个停止。

                            表5假设ApplMgr已经在JVM中运行。应用程序类以前已由ApplMgr装载。应用程序已经正在运行。结果所希望的应用程序停止执行。代理程序User＝指令ApplClient停止在结点HP上的应用程序‘test’。ApplClient＝启动应用程序的主机侧程序ClientProtocol＝处理客户的网络通讯的主机侧类ServeProtocol＝处理ApplMgr网络通讯的服务器侧类ApplMgr＝应用程序管理程序类Application＝包含被停止的ApplBase实例的应用程序类ApplBase＝被停止的执行应用程序实例

    如图8中所示，一个停止操作用从一个客户用户应用程序例如客户用户类ApplClientU 516至客户应用程序ApplClient 508的一个用户请求802来开始。在这个例子中，客户用户类ApplClientU 516通过遵照先传送一个‘E’字符(为‘end’)，后面跟应用程序名‘test’，再后面跟类数据要传送抵达的网络结点‘HP’的协议产生一个停止请求。请求802使得ApplClient 508被运行以便停止在结点‘HP’上应用程序‘test’的执行。ApplClient 508调用ClientProtocol.StopAppl()804方法停止应用程序。ClientProtocol 506形成一个至结点‘HP’上的ServerProtocol 504的网络连接，同时发送806一个停止消息。ServerProtocol 504译码停止请求，然后调用ApplMgr.StopAppl()方法808。ApplMgr 502查出正确的应用程序目标510，然后调用810在应用程序510上的stopAppl()方法。应用程序目标510通过传递到stopAppl()的名字查出ApplBase 514实例，同时调用它的terminate()方法812。应用程序则使用Thread.join()以确保ApplBase已终止。应用程序目标510更好ApplBase 514实例的状态814以便终止。

    停止一个ApplBase 514实例是一个异步事件，因为应用程序正在以它自己的线索表执行。可能希望实际上不等待应用程序停止，因为如果应用程序不轮询它的终止标志，它将不停止。因此，在实现中，设计可以另外使用一个具有超时的join()方法，然后通过调用stop()迫使终止。

    图9是说明当在执行应用程序510的一个实例期间出现低存储器或无存储器状态时类之间通讯的系统500的一个方块图。表6规定初始假设，存储器溢出状态的结果和执行处理该状态所要求的代理程序。如所描述的那样，假设一个应用程序管理程序类ApplMgr 502正在嵌入设备20的JVM22中运行，同时一个或多个应用程序类被装载和执行。

                               表6假设ApplMgr已经在JVM中运行。一个或多个应用程序类被装载和执行结果JVM和ApplMgr继续执行，同时通过管理用户应用程序类和实例高速缓存器释放存储器。代理程序User＝指令ApplClient停止在结点‘HP’上应用程序‘test’。ApplClient＝启动应用程序的主机侧程序ClientProtocol＝处理客户的网络通讯的主机侧类ServeProtocol＝处理ApplMgr网络通讯的服务器侧类ApplMgr＝应用程序管理程序类Application＝包含被停止的ApplBase实例的应用程序类ApplBase＝被停止的执行应用程序实例

    如图9中所示，一个运行应用程序510的一个实例ApplBase 514产生一个OutofMemoryError 902。最好Out of Memory Error由Application.run()方法内的存储器管理处理程序27处理904。处理程序27通过调用一个ApplMgr.out of Memory()方法906把状态通知ApplMgr 502。应用程序510则从run()返回以便停止ApplBase514线索表908。ApplMgr 502反复通过它的应用程序高速缓存器52，通过调用Application applcount()方法908发现不具有已执行的ApplBases的类。那些没有执行的ApplBases的应用程序被指示到freeMemory()910，其使得它们能从应用程序高速缓存器52中转除它们的类。ApplMgr 502则从它的应用程序高速缓存器52中删除912那些应用程序，同时调用Runtime.gc()914以使垃圾回收站回收未标记的目标因而释放存储器。

    如上面详细描述的那样，本发明提供一个应用程序管理程序和API特性，其在一个Java虚拟机内运行，打算将该Java虚拟机用于电子设备或装置中以及在具有有限资源限制环境的其它嵌入系统中。当存储器资源变得有限时本发明提供高速缓存器和终止应用程序供将来运行的灵活性，以便为较高优先权的应用程序释放存储器。