java进程抢占代码,抢占一个进程

java 多进程并发控制怎么做?

进程间的通讯无非就是读写文件，socket通讯或者使用共享内存。 你不想用读写文件的方式，那就用共享内存或者socket通讯的方式。我个人觉得用socket比较简单，也许是因为我对socket比较熟悉。 下面是一篇java实现共享内存的文章，java没法管理内存，其实他也是靠创建映像文件来实现的。 共享内存在java中的实现 在jdk1.4中提供的类MappedByteBuffer为我们实现共享内存提供了较好的方法。该缓冲区实际上是一个磁盘文件的内存映像。二者的变化将保持同步，即内存数据发生变化会立刻反映到磁盘文件中，这样会有效的保证共享内存的实现。 将共享内存和磁盘文件建立联系的是文件通道类：FileChannel。该类的加入是JDK为了统一对外部设备（文件、网络接口等）的访问方法，并且加强了多线程对同一文件进行存取的安全性。例如读写操作统一成read和write。这里只是用它来建立共享内存用，它建立了共享内存和磁盘文件之间的一个通道。 打开一个文件建立一个文件通道可以用RandomAccessFile类中的方法getChannel。该方法将直接返回一个文件通道。该文件通道由于对应的文件设为随机存取文件，一方面可以进行读写两种操作，另一方面使用它不会破坏映像文件的内容（如果用FileOutputStream直接打开一个映像文件会将该文件的大小置为0，当然数据会全部丢失）。这里，如果用 FileOutputStream和FileInputStream则不能理想的实现共享内存的要求，因为这两个类同时实现自由的读写操作要困难得多。 下面的代码实现了如上功能，它的作用类似UNIX系统中的mmap函数。 // 获得一个只读的随机存取文件对象 RandomAccessFile RAFile = new RandomAccessFile(filename,"r"); // 获得相应的文件通道 FileChannel fc = RAFile.getChannel(); // 取得文件的实际大小，以便映像到共享内存 int size = (int)fc.size(); // 获得共享内存缓冲区，该共享内存只读 MappedByteBuffer mapBuf = fc.map(FileChannel.MAP_RO,0,size); // 获得一个可读写的随机存取文件对象 RAFile = new RandomAccessFile(filename,"rw"); // 获得相应的文件通道 fc = RAFile.getChannel(); // 取得文件的实际大小，以便映像到共享内存 size = (int)fc.size(); // 获得共享内存缓冲区，该共享内存可读写 mapBuf = fc.map(FileChannel.MAP_RW,0,size); // 获取头部消息：存取权限 mode = mapBuf.getInt(); 如果多个应用映像同一文件名的共享内存，则意味着这多个应用共享了同一内存数据。这些应用对于文件可以具有同等存取权限，一个应用对数据的刷新会更新到多个应用中。 为了防止多个应用同时对共享内存进行写操作，可以在该共享内存的头部信息加入写操作标志。该共享内存的头部基本信息至少有： int Length； // 共享内存的长度。 int mode; // 该共享内存目前的存取模式。 共享内存的头部信息是类的私有信息，在多个应用可以对同一共享内存执行写操作时，开始执行写操作和结束写操作时，需调用如下方法： public boolean StartWrite() { if(mode == 0) { // 标志为0，则表示可写 mode = 1; // 置标志为1，意味着别的应用不可写该共享内存 mapBuf.flip(); mapBuf.putInt(mode); // 写如共享内存的头部信息 return true; } else { return false; // 指明已经有应用在写该共享内存，本应用不可写该共享内存 } } public boolean StopWrite() { mode = 0; // 释放写权限 mapBuf.flip(); mapBuf.putInt(mode);

相关问答

Q1: JAVA程序开始之后VIRT占用过高是什么原因造成的，怎么解决

从代码的角度，软件开发人员主要关注java.lang.OutOfMemoryError: Java heap space异常，减少不必要的对象创建，同时避免内存泄漏。

现在以一个实际的例子分析内存占用的故障排查。

通过top命令，发现PID为9004的Java进程一直占用比较高的内存不释放（24.7%），出现高内存占用的故障。

ps -mp 9004 -o THREAD,tid,time,rss,size,%mem

发现PS命令可以查到具体进程的CPU占用情况，但是不能查到一个进程下具体线程的内存占用情况

Q2: 用怎样的JAVA代码结束指定进程？

1 线程正常执行完毕，正常结束。 也就是让run方法执行完毕，该线程就会正常结束。 2 监视某些条件，结束线程的不间断运行。 然而，常常有些线程是伺服线程。它们需要长时间的运行，只有在外部某些条件满足的情况下，才能关闭这些线程。 通常，它们执行在一个while(true)的死循环中。 如: publicvoid run() { while(true){ someWork(); if(finished){ break; } try { Thread.sleep(10000); } catch (InterruptedException e) { /* TODO自动生成 catch 块 * */ e.printStackTrace(); } } } 我们可以在while死循环内，每次循环时，察看外部条件，看看是否需要关闭当前线程。如果是，就break，跳出死循环，或者是抛出异常，跳出死循环，结束线程。 3 捕获InterruptedException 运行时异常，中断当前线程。 有些执行伺服任务的线程，在while(true)这样的死循环内部，是一个阻塞中的方法。此时，就不能采用第二种方法了。因为，当该方法没有返回时，该线程一直处于阻塞当中，根本无法执行其他语句。 此时，就需要调用该线程的interrupt方法，产生一个InterruptedException运行时异常，是阻塞中的那个方法抛出这个异常，从而让我们有机会结束这个线程的执行。 如： publicvoid run() { while(true){ try { // getSendMessages 是BlockingQueue类。它的take方法将会阻塞！ responseMessage = this.getSendMessages().take(); } catch (InterruptedException e1) { thrownew RuntimeException(); //或者break; } someWork(); } 一个外部的Thread 对象 指向这个线程。 需要结束这个线程时，只需要调用thread对象的interrupt（） 方法，就会在responseMessage = this.getSendMessages（）。take（）； 这条语句中产生一个InterruptedException异常，从而结束该线程的阻塞状态，通过抛出异常，或者break跳出死循环，结束这个线程。

Q3: java占用cpu高？

java进程占用CPU过高常见的两种情况：

1,代码中有死循环或者接近死循环的操作

2,快速创建大量临时变量，导致频繁触发gc回收

Q4: Java进程怎么实现？

Java中多进程编程的实现,和多线程一样,多进程同样是实现并发的一种方式,需要的朋友可以参考下

1.Java进程的创建

Java提供了两种方法用来启动进程或其它程序：

（1）使用Runtime的exec()方法

（2）使用ProcessBuilder的start()方法

1.1 ProcessBuilder

ProcessBuilder类是J2SE 1.5在java.lang中新添加的一个新类，此类用于创建操作系统进程，它提供一种启动和管理进程（也就是应用程序）的方法。在J2SE 1.5之前，都是由Process类处来实现进程的控制管理。

每个 ProcessBuilder 实例管理一个进程属性集。start() 方法利用这些属性创建一个新的 Process 实例。start() 方法可以从同一实例重复调用，以利用相同的或相关的属性创建新的子进程。

每个进程生成器管理这些进程属性：

命令 是一个字符串列表，它表示要调用的外部程序文件及其参数（如果有）。在此，表示有效的操作系统命令的字符串列表是依赖于系统的。例如，每一个总体变量，通常都要成为此列表中的元素，但有一些操作系统，希望程序能自己标记命令行字符串——在这种系统中，Java 实现可能需要命令确切地包含这两个元素。

环境 是从变量 到值 的依赖于系统的映射。初始值是当前进程环境的一个副本（请参阅 System.getenv()）。

工作目录。默认值是当前进程的当前工作目录，通常根据系统属性 user.dir 来命名。

redirectErrorStream 属性。最初，此属性为 false，意思是子进程的标准输出和错误输出被发送给两个独立的流，这些流可以通过 Process.getInputStream() 和 Process.getErrorStream() 方法来访问。如果将值设置为 true，标准错误将与标准输出合并。这使得关联错误消息和相应的输出变得更容易。在此情况下，合并的数据可从 Process.getInputStream() 返回的流读取，而从 Process.getErrorStream() 返回的流读取将直接到达文件尾。