java 多进程并发控制怎么做?
如题。a.class在执行时如何保证a.class不能再被当成新进程执行?a.class在执行时如何在其他进程运行a.class时开启一个线程来完成另一个进程的任务,却不...
如题。
a.class在执行时如何保证a.class不能再被当成新进程执行?
a.class在执行时如何在其他进程运行a.class时开启一个线程来完成另一个进程的任务,却不新建进程?
我知道利用读写文件和剪贴板可以,但是这样做负面影响太大,并且达不到我做这个东西的目的。
其实这就是一个进程间通信的问题。
bearfig谢谢你,但是你的回答是针对线程的。对我很有帮助但是不能解决眼前的问题。 展开
a.class在执行时如何保证a.class不能再被当成新进程执行?
a.class在执行时如何在其他进程运行a.class时开启一个线程来完成另一个进程的任务,却不新建进程?
我知道利用读写文件和剪贴板可以,但是这样做负面影响太大,并且达不到我做这个东西的目的。
其实这就是一个进程间通信的问题。
bearfig谢谢你,但是你的回答是针对线程的。对我很有帮助但是不能解决眼前的问题。 展开
3个回答
展开全部
进程间的通讯无非就是读写文件,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); // 写入共享内存头部信息
return true;
}
这里提供的类文件mmap.java封装了共享内存的基本接口,读者可以用该类扩展成自己需要的功能全面的类。
如果执行写操作的应用异常中止,那么映像文件的共享内存将不再能执行写操作。为了在应用异常中止后,写操作禁止标志自动消除,必须让运行的应用获知退出的应用。在多线程应用中,可以用同步方法获得这样的效果,但是在多进程中,同步是不起作用的。方法可以采用的多种技巧,这里只是描述一可能的实现:采用文件锁的方式。写共享内存应用在获得对一个共享内存写权限的时候,除了判断头部信息的写权限标志外,还要判断一个临时的锁文件是否可以得到,如果可以得到,则即使头部信息的写权限标志为1(上述),也可以启动写权限,其实这已经表明写权限获得的应用已经异常退出,这段代码如下:
// 打开一个临时的文件,注意同一共享内存,该文件名要相同,可以在共享文件名后加后缀“.lock”。
RandomAccessFile fis = new RandomAccessFile("shm.lock","rw");
// 获得文件通道
FileChannel lockfc = fis.getChannel();
// 获得文件的独占锁,该方法不产生堵塞,立刻返回
FileLock flock = lockfc.tryLock();
// 如果为空,则表明已经有应用占有该锁
if(flock == null) {
...// 不能执行写操作
}
else {
...// 可以执行写操作
}
该锁会在应用异常退出后自动释放,这正是该处所需要的方法。
你不想用读写文件的方式,那就用共享内存或者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); // 写入共享内存头部信息
return true;
}
这里提供的类文件mmap.java封装了共享内存的基本接口,读者可以用该类扩展成自己需要的功能全面的类。
如果执行写操作的应用异常中止,那么映像文件的共享内存将不再能执行写操作。为了在应用异常中止后,写操作禁止标志自动消除,必须让运行的应用获知退出的应用。在多线程应用中,可以用同步方法获得这样的效果,但是在多进程中,同步是不起作用的。方法可以采用的多种技巧,这里只是描述一可能的实现:采用文件锁的方式。写共享内存应用在获得对一个共享内存写权限的时候,除了判断头部信息的写权限标志外,还要判断一个临时的锁文件是否可以得到,如果可以得到,则即使头部信息的写权限标志为1(上述),也可以启动写权限,其实这已经表明写权限获得的应用已经异常退出,这段代码如下:
// 打开一个临时的文件,注意同一共享内存,该文件名要相同,可以在共享文件名后加后缀“.lock”。
RandomAccessFile fis = new RandomAccessFile("shm.lock","rw");
// 获得文件通道
FileChannel lockfc = fis.getChannel();
// 获得文件的独占锁,该方法不产生堵塞,立刻返回
FileLock flock = lockfc.tryLock();
// 如果为空,则表明已经有应用占有该锁
if(flock == null) {
...// 不能执行写操作
}
else {
...// 可以执行写操作
}
该锁会在应用异常退出后自动释放,这正是该处所需要的方法。
展开全部
在Doug lea的那本著名的《Java并发编程—设计原则与模式》,英文名"Concurrent Programming in Java™: Design Principles and Patterns, Second Edition",书中提到可以用信号量Semaphore实现互斥锁Mutex。虽然java中是通过synchronize关键字提供锁,并用这个基础设施实现信号量的。在有的系统中只有信号量这一原语,锁是通过信号量实现的。代码如下:
import java.util.concurrent.Semaphore;
public class Mutex ...{
private Semaphore s = new Semaphore(1);
public void acquire() throws InterruptedException ...{
s.acquire();
}
public void release()...{
s.release();
}
public boolean attempt(int ms) throws InterruptedException ...{
return s.tryAcquire(ms);
}
}
上面的代码只能在java5中编译通过,因为Semaphore是在java5中才提供的。我在读上面的代码时有疑问。因为如果错误的连续调用release两次,然后两个线程都调用acquire,岂不是这两个线程都可以同时运行,从而违背了互斥锁的定义?为了证明我的猜测,写了如下的代码:
public class TestMutex ...{
public static void main(String[] args) throws InterruptedException...{
Mutex mutex=new Mutex();
mutex.acquire();
mutex.release();
mutex.release();
new MyThread(mutex).start();
new MyThread(mutex).start();
}
}
class MyThread extends Thread...{
private Mutex mutex;
public MyThread(Mutex mutex) ...{
this.mutex=mutex;
}
public void run()...{
try ...{
mutex.acquire();
} catch (InterruptedException e1) ...{
throw new RuntimeException(e1);
}
for(int i=0;i<10;i++)...{
System.out.print(i);
if(i%3==0)...{
try ...{
Thread.sleep(100);
} catch (InterruptedException e) ...{
e.printStackTrace();
}
}
}
mutex.release();
}
}
该程序的输出如下:
00123123456456789789
从而证实了我的猜测。
作为对比,下面是采用synchronized关键字的互斥锁方案:
public class TestLock ...{
public static void main(String[] args) throws InterruptedException...{
new MyThread2().start();
new MyThread2().start();
}
}
class MyThread2 extends Thread...{
public void run()...{
synchronized(TestLock.class)...{
for(int i=0;i<10;i++)...{
System.out.print(i);
if(i%3==0)...{
try ...{
Thread.sleep(100);
} catch (InterruptedException e) ...{
e.printStackTrace();
}
}
}
}
}
}
该程序的输出如下:
01234567890123456789
可见两个线程确实互斥运行。
这个问题产生的原因是虽然在Mutex的定义中"private Semaphore s = new Semaphore(1)",也就是该信号量的初始permits是1,但是在此后每次调用release方法都会导致permits加一。如果能限制permits最大值1,最小值0,那就是真正的Mutex了。
import java.util.concurrent.Semaphore;
public class Mutex ...{
private Semaphore s = new Semaphore(1);
public void acquire() throws InterruptedException ...{
s.acquire();
}
public void release()...{
s.release();
}
public boolean attempt(int ms) throws InterruptedException ...{
return s.tryAcquire(ms);
}
}
上面的代码只能在java5中编译通过,因为Semaphore是在java5中才提供的。我在读上面的代码时有疑问。因为如果错误的连续调用release两次,然后两个线程都调用acquire,岂不是这两个线程都可以同时运行,从而违背了互斥锁的定义?为了证明我的猜测,写了如下的代码:
public class TestMutex ...{
public static void main(String[] args) throws InterruptedException...{
Mutex mutex=new Mutex();
mutex.acquire();
mutex.release();
mutex.release();
new MyThread(mutex).start();
new MyThread(mutex).start();
}
}
class MyThread extends Thread...{
private Mutex mutex;
public MyThread(Mutex mutex) ...{
this.mutex=mutex;
}
public void run()...{
try ...{
mutex.acquire();
} catch (InterruptedException e1) ...{
throw new RuntimeException(e1);
}
for(int i=0;i<10;i++)...{
System.out.print(i);
if(i%3==0)...{
try ...{
Thread.sleep(100);
} catch (InterruptedException e) ...{
e.printStackTrace();
}
}
}
mutex.release();
}
}
该程序的输出如下:
00123123456456789789
从而证实了我的猜测。
作为对比,下面是采用synchronized关键字的互斥锁方案:
public class TestLock ...{
public static void main(String[] args) throws InterruptedException...{
new MyThread2().start();
new MyThread2().start();
}
}
class MyThread2 extends Thread...{
public void run()...{
synchronized(TestLock.class)...{
for(int i=0;i<10;i++)...{
System.out.print(i);
if(i%3==0)...{
try ...{
Thread.sleep(100);
} catch (InterruptedException e) ...{
e.printStackTrace();
}
}
}
}
}
}
该程序的输出如下:
01234567890123456789
可见两个线程确实互斥运行。
这个问题产生的原因是虽然在Mutex的定义中"private Semaphore s = new Semaphore(1)",也就是该信号量的初始permits是1,但是在此后每次调用release方法都会导致permits加一。如果能限制permits最大值1,最小值0,那就是真正的Mutex了。
参考资料: http://dev.csdn.net/author/javayuan/fc8f5b9b7bf747c298045c3a54dd186c.html
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
第一,JVM中没有进程的概念。所有都是线程。请复习概念。
如果是同一个JVM中线程的通讯,参见一楼,我不再浪费口水。
如果是不同JVM间的通讯,首先要问你自己为什么需要两个JVM。这不是通常的情况。一般都不需要这么做,除非你写游戏client-server。
如果确定需要,采用subscribe模型异步通讯,或采用TCP直连同步通讯。直连时使用java.nio不要使用java.io。
如果是同一个JVM中线程的通讯,参见一楼,我不再浪费口水。
如果是不同JVM间的通讯,首先要问你自己为什么需要两个JVM。这不是通常的情况。一般都不需要这么做,除非你写游戏client-server。
如果确定需要,采用subscribe模型异步通讯,或采用TCP直连同步通讯。直连时使用java.nio不要使用java.io。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询