「javacpu分配」javacpu分配不均衡

本篇文章给大家谈谈javacpu分配，以及javacpu分配不均衡对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、java中一个线程启动后如何使CPU立即分配给它使它运行
• 2、Java的多线程和CPU
• 3、java参数中的分配cpu
• 4、如何让java更好的利用多cpu?
• 5、Java应用程序中如何动态的分配CPU资源?

java中一个线程启动后如何使CPU立即分配给它使它运行

sleep(1000),是把当前线程睡眠1000ms，1000ms之后，有cpu的时间片控制分配，轮到你这个线程运行，你才能运行；由于cpu运行速度特别快，所以我们看起来好像是1000ms之后就立马运行了，但很多情况都是大于1000ms的

Java的多线程和CPU

CPU对于各个线程的调度是随机的（分时调度），而在Java中，JVM负责线程的调度，可更好地分配CPU的使用权。对于线程的调度一般有两种模式，分时调度和抢占式调度。分时调度是按照顺序平均分配；抢占调度是按照优先级来进行分配。

java参数中的分配cpu

应该是没有的，cpu针对java没有影响吧，他只是去分配内存的位置及大小空间

如何让java更好的利用多cpu?

几个意见大致如下，第一，不能，因为“进程是CPU进行调度的单位，而JVM是一个进程，于是就只能跑在一个CPU上”。第二，“进程是CPU进行调度的单位，这没错，但是OS负责将一个进程在不同的CPU上调度到另外一个CPU上，而这个进程，则是由不同的线程构成的，那么说，线程还是在不同的CPU上运行了”。我更倾向于第二种解释，于是核心问题就变成了讨论“JVM能不能够将线程安排到不同的CPU上去运行呢？”。

最终，在SUN公司授权的《Java核心技术》，第7版卷II，第8版卷I，有关于“可运行线程”中，找到如下两句话：

“今天，人们很可能有单台拥有多个CPU的计算机，但是，并发执行的进程数并不是CPU数目制约的。操作系统的时间片分配给每一个进程，给人并行处理的感觉”。

好吧，上面的这句话，并不能说明这个答案，但是当我看到下面的这句原话的时候，感觉答案就在这里了:

"在具有多个处理器的机器上，每一个处理器运行一个线程，可以有多个线程并行运行。当然，如果线程的数目多于处理器的数目，调度器依然采用时间片机制"。这句话足以用来反驳那个出问题的人了，因为他的答案本身就是错的。

尽管，尽信书不如无书，但是，还能有更好的选择么？带着这个问题，继续走下去~ Fighting~ ziwen@163.com I enjoy PM、Java、Oracle. I'm an English lover as well~ ho ho~

后记：

更详细的信息可以参见有关Java虚拟机实现的“并发”系列讲解，基本上每本关于Java虚拟机有关的书籍以及官方文档都会讲到JVM如何实现线程的几种方式。 基于系统内核，基于用户线程等等实现。JVM中的线程实现是本地化的~ 本地化的意思就是与平台有关了，尽管与平台有关，但是线程调度，仍旧是最佳高效的方式，有资料曾说过：线程的创建销毁与调度的开销是进程的三十分之一。

Java应用程序中如何动态的分配CPU资源?

方案选择

在考虑动态分配CPU资源实施方案时，往往有以下两点要求：

1. 须充分利用现有硬件资源，在系统空闲时，让低优先级任务也能够得到系统所能给予最快响应。

2.当硬件资源超负荷运行时，虽然系统中有大规模、多数量任务不能处理，但它不应受影响，而能够顺利处理那些能够被处理、最重要高优先级任务。

多任务系统要用多线程实现最简单方法就是将线程和任务一一对应，动态调整线程优先级，利用线程调度来完成CPU资源在不同任务间动态分配。这种思路在以前使用本地化代码(Native Code)，充分利用特定硬件和操作系统技巧基础上是基本可行。但在跨平台Java环境中，这个思路对仅有小规模任务数简单系统才可行，原因有以下两点：

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

2. 由于在Java系统中，线程被包装在一个Java语言对象类—Thread中，所以为了完成Java语言对象和操作系统线程对应，Java线程系统开销还是比较大(在NT 4.0中，平均每个线程大致占用30KB内存)。因此如果让Thread对象个数和成千上万任务数同比例增长，就显然是不合理。

内容摘要：本文利用协调式多任务模型，提出一个与平台无关、并且能在任务间动态分配CPU资源方案。

综上所述，根据并发多任务大规模需求和Java平台固有特点，想要利用Java Thread对象优先级调整CPU资源分配是非常困难，所以应该尽量避免让线程和任务直接对应，也尽量避免使用操作系统线程优先级调度机制。

解决方案

根据以上分析，问题症结在于：多任务系统中任务在Java语言中对应以及任务间相互调度。

　从本质上看，一个任务就是一系列对象方法调用序列，与JavaThread对象或者别类对象没有必然联系。在避免使用不同操作系统线程调度且同时Java虚拟机又没有线程调度能力情况下，要想构造一个协调式多任务系统，让各个任务相互配合就成了最直接思路。协调式多任务系统一般有以下特点：

1. 任务由消息驱动，消息响应代码完成任务逻辑处理;

2. 消息队列完成消息存储和管理，从而利用消息处理次序体现任务优先级不同;

3. 任务中耗时消息响应逻辑能够主动放弃CPU资源，让别任务执行(像Windows 3.1中Yield函数、Visual Basic中DoEvents语句)。

可能出于巧合，Java语言具有构造协调式多任务系统天然条件。Java对象方法不仅是一个函数调用，它还是一个java.lang.reflect.Method类对象。而所有对象方法都可以通过Method类invoke方法调用。如果能使每个任务所对应一系列方法全部以对象形式包装成消息，放到消息队列中，然后再按照自己优先级算法将队列中消息取出，执行其Method对象invoke调用，那么一个基本协调式多任务系统就形成了。其中，任务优先级和线程优先级没有绑定关系。该系统主体调度函数可以设置成一个“死循环”，按照需要优先级算法处理消息队列。对于有多重循环、外设等待等耗时操作消息响应函数，可以在响应函数内部递归调用主体调度函数,这一次调用把原来“死循环”改成在消息队列长度减少到一定程度(或者为空)后退出。退出后，函数返回，执行刚才没有完成消息响应逻辑，这样就非常自然地实现了协调式系统中任务主动放弃CPU资源要求。

javacpu分配的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于javacpu分配不均衡、javacpu分配的信息别忘了在本站进行查找喔。