如何在java应用程序中动态分配cpu资源

上传人:xzh****18 文档编号:35468851 上传时间:2018-03-16 格式:DOC 页数:4 大小:29KB
返回 下载 相关 举报
如何在java应用程序中动态分配cpu资源_第1页
第1页 / 共4页
如何在java应用程序中动态分配cpu资源_第2页
第2页 / 共4页
如何在java应用程序中动态分配cpu资源_第3页
第3页 / 共4页
如何在java应用程序中动态分配cpu资源_第4页
第4页 / 共4页
亲,该文档总共4页,全部预览完了,如果喜欢就下载吧!
资源描述

《如何在java应用程序中动态分配cpu资源》由会员分享,可在线阅读,更多相关《如何在java应用程序中动态分配cpu资源(4页珍藏版)》请在金锄头文库上搜索。

1、Java 的线程调度操作在运行时是与平台无关的。一个多任务系统需要在任务之 间实现 QoS(Quality of Service)管理时,如果 CPU 资源的分配基于 Java 线 程的优先级,那么它在不同平台上运行时的效果是很难预测的。本文利用协调 式多任务模型,提出 一个与平台无关、并且能在任务间动态分配 CPU 资源的方 案。现在,由于计算机系统已经从人机交互逐步向机机交互转化,计算机和计算机 之间的业务对于时间的要求非常高。软件系统对于业务的支持已经不仅表现为 对 不同业务的逻辑和数据(算法+数据结构)支持,而且还表现为对同时处理 不同任务的时效性(任务响应速度)支持。一般,任务响应的

2、速度可以通过算 法优化及并 行运算分担负载等手段来提高。但是,用户业务逻辑的复杂度决定 了算法优化的发挥空间,硬件规模决定了所能够承担负载的大小。我们利用 Java 平台的特点, 借鉴协调式多任务思想,使 CPU 资源能够在任务间动态分 配,从而为时间要求强的任务分配更多的 CPU 运行资源。这也可以充分利用现 有硬件,为用户业务提供 最大的保障。用 Java 解决问题本着软件系统结构和现实系统结构一致的思想,开发复杂业务服务的程序一般 按照计算机任务和现实业务对应的思路,最终形成一个大规模的多任务系统。 由 于其跨平台性,Java 系统可以随着业务的扩大,平滑地升级到各种硬件平 台上。由于

3、Java 自身的发展及其应用场合的不断扩大,用它实现多任务系统已 经成 为当前的应用方向。在 J2EE(Java2 Enterprise Edition)推出以后, Sun 公司已经将 Java 的重心放在了服务器端(Server Side)系统的构造上。 由于客户/服务器模型固有的多对一的关系,服务器端程序也必然是一个多任务 系统。在 Java 多任务应用中,动态地将 CPU 资源在任务间分配有很重要的意义。比如 一个 Internet 服务商的系统往往有多种任务同时运行,有 HTTP、FTP、MAIL 等协议的支持,也有商务、娱乐、生活、咨询等业务的服务。在白天,网站希 望系统的 CPU

4、资源尽量保障网上用户的服务质量,提高 电子商务等任务的响应 速度;晚上则希望让自己的娱乐服务和资料下载尽可能满足下班后人们的需要。 另外,在新兴的网管(比如 TMN, Telecommunication Management Network) 等应用领域中,服务程序往往需要支持成千上万个并发响应事件的被管理对象 (MO,Managed Object)。对于被管理对象执行的操作,不同用户在不同时刻 往往有不同的时间要求。方案选择在考虑动态分配 CPU 资源的实施方案时,往往有以下两点要求:1. 须充分利用现有硬件资源,在系统空闲时,让低优先级任务也能够得到系统 所能给予的最快响应。2.当硬件资源

5、超负荷运行时,虽然系统中有大规模、多数量的任务不能处理, 但它不应受影响,而能够顺利处理那些能够被处理的、最重要的高优先级任 务。多任务系统要用多线程实现的最简单方法就是将线程和任务一一对应,动态调 整线程的优先级,利用线程调度来完成 CPU 资源在不同任务间动态分配。这种 思路在以前使用本地化代码(Native Code),充分利用特定硬件和操作系统技 巧的基础上是基本可行的。但在跨平台的 Java 环境中,这个思路对仅有小规模 任务数的简单系统才可行,原因有以 下两点:1. Java 的线程虽然在编程角度(API)是与平台无关的,但它的运行效果却和 不同操作系统平台密切相关。为了利用更多的

6、 CPU 资源,Java 中的一个线程 (Thread)就对应着不同操作系统下的一个真实线程。因为 Java 虚拟机没有实 现线程的调度,所以这些 Java 的线程在不同操作系统调度下运行的差异 性也 就比较明显。例如在 Windows 系统中,不仅线程的优先级少于 Java API 参数规 定的十个优先级,而且微软明确反对程序员动态调整线程优先级。即使在操作 系统中有足够的优先权,让线程优先级的参数和真实线程的优先级对应, 不同 操作系统的调度方式也会有许多不同。这最终会造成代码在不同平台上的行为 变得不可预测。这就很难满足复杂的、大规模并发任务的众多优先级需求,从 而很 难达到用户业务需要

7、达到的效果。2. 由于在 Java 系统中,线程被包装在一个 Java 语言的对象类Thread 中, 所以为了完成 Java 语言对象和操作系统线程的对应,Java 线程的系统 开销还 是比较大的(在 NT 4.0 中,平均每个线程大致占用 30KB 内存)。因此如果让 Thread 对象个数和成千上万的任务数同比例增长,就显然是不合理的。综上所述,根据并发多任务的大规模需求和 Java 平台固有的特点,想要利用 Java Thread 对象的优先级调整 CPU 资源的分配是非常困难的,所以应该尽量 避免让线程和任务直接对应,也尽量避免使用操作系统线程优先级的调度机制。解决方案根据以上分析,

8、问题的症结在于:多任务系统中的任务在 Java 语言中的对应以 及任务间的相互调度。从本质上看,一个任务就是一系列对象方法的调用序列,与 Java 的 Thread 对 象或者别的类的对象没有必然联系。在避免使用不同操作系统线程调度 且同时 Java 虚拟机又没有线程调度能力的情况下,要想构造一个协调式多任务系统, 让各个任务相互配合就成了最直接的思路。协调式多任务系统一般有以下特 点:1. 任务由消息驱动,消息的响应代码完成任务逻辑的处理;2. 消息队列完成消息的存储和管理,从而利用消息处理的次序体现任务优先级 的不同;3. 任务中耗时的消息响应逻辑能够主动放弃 CPU 资源,让别的任务执行

9、(像 Windows 3.1 中的 Yield 函数、Visual Basic 中的 DoEvents 语句)。可能出于巧合,Java 语言具有构造协调式多任务系统天然的条件。Java 对象的 方法不仅是一个函数调用,它还是一个 java.lang.reflect.Method 类的对象。 而所有对象的方法都可以通过 Method 类的 invoke 方法调用。如果能使每个任 务所对应 的一系列方法全部以对象形式包装成消息,放到消息队列中,然后再 按照自己的优先级算法将队列中的消息取出,执行其 Method 对象的 invoke 调 用,那 么一个基本的协调式多任务系统就形成了。其中,任务的优

10、先级和线程 的优先级没有绑定关系。该系统的主体调度函数可以设置成一个“死循环”, 按照需要的优先 级算法处理消息队列。对于有多重循环、外设等待等耗时操作 的消息响应函数,可以在响应函数内部递归调用主体调度函数,这一次调用把 原来的“死循环”改成在 消息队列长度减少到一定程度(或者为空)后退出。 退出后,函数返回,执行刚才没有完成的消息响应逻辑,这样就非常自然地实 现了协调式系统中任务主动放弃 CPU 资源的要求。如果仅仅做到这一步,完成一个像 Windows 3.1 中的多任务系统,实际只用了 一个线程,没有利用 Java 多线程的特点。应该注意到,虽然 Java 系统中线程 调度与平台相关,

11、但是相同优先级的线程之 间分时运行的特点基本上是不受特 定平台影响的。各个相同优先级的线程共享 CPU 资源,而线程又被映射成了 Java 语言中的 Thread 对象。这些对象就可 以被认为是 CPU 资源的代表。 Thread 与线程执行代码主体的接口Runnable 之间是多对一的关系。一个 Runnable 可以被多个 Thread 执行。只要将 Runnable 的执行代码设置成上述的 消息调度函数,并和消息队列对应上,那么就可以通过控制为它服务的 Thread 个数来决定消息队列执 行的快慢,并且在运行时可以动态地新增(new)和退 出 Thread 对象。这样就能任意调整不同消息

12、队列在执行时所占用 CPU 资源的多 少。至此,任何一个 Java 调用都可以在 Thread 个数不同的消息队列中选择, 并可以调整这些消息队列服务的 Thread 个数,从而实现在运行时调整任务所占 用的 CPU 资 源。纵观整个方案,由于仅仅基于 Java 语言固有的 Method 对象,不同任务间动态 分配 CPU 资源并没有对任务的性质及其处理流程有任何限制,那么在 消息队列 中没有高优先级消息时,低优先级消息的处理函数自然会全部占用 CPU 资源。 在不同消息队列处理速度任意设置时,并没有将特定的消息限制在快的或者 慢 的消息队列上。如果系统的负荷超出(比如消息队列长度超过一定限制

13、),只 要将队列中低优先级消息换出或者拒绝不能处理的消息进入,那么系统的运行 就可以 基本上不受负荷压力的影响,从而最大保障用户的关键业务需求。当然,协调式多任务的思想也有其局限性,主要就是它的调度粒度比较大。系 统能够保证的粒度是一次消息处理过程。如果消息处理逻辑非常费时,那么编 程 人员就必须再处理函数内部,让系统主动让出 CPU 资源。这虽然需要在处理 消息响应逻辑时增加一个考虑因素,但是,在 Windows 系统盛行的今天,这是一 个已经被普遍接受的思路。由于方案中并没有局限为消息队列服务的线程数 目,所以一个长时间的消息响应只会影响一个线程,而不会对整个系统产生致 命的影响。 除了调

14、度粒度的问题以外,还有访问消息队列操作在各个线程间互 斥的问题。取出消息的过程是串行化的,因此对于这一瓶颈的解决方案就是: 假设取出一条消息的 操作相对于处理消息的消耗可以忽略不计,那么对于多次 调用且仅有两三行响应逻辑的消息,编程人员通过函数调用就可以直接执行。前面比较详细地阐述了多任务系统中任务的划分以及执行等内容。虽然这些是 一个系统的核心,但是在一个实用的系统中,还需要任务间的同步、互斥等机 制。在上述框架内,互斥可以简单地用 Java 的 Synchronized 机制实现。由于 任务可以主动让出执行权限,要实现等待(Wait 任务中止)和通知 (Notify 任务继续),从而实现任务同步也就比较容易了。

展开阅读全文
相关资源
相关搜索

当前位置:首页 > IT计算机/网络 > 多媒体应用

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号