奇怪了，为什么会取不到我机子上更改后的IP?

[hk2000c]

我想在机子上运行一个程序，有一个功能是使它能获得自己机器的IP地址。而且每格一段时间进行一次轮询，以检查IP地址的改动。我试图手动修改win2000的网络连接内TCP/IP设置，修改IP,并用ping 检验是否成功。但是这段代码在轮询期间，不能捕获修改后的IP，这是为什么呢？

import java.net.*;
import javax.activation.*;
import javax.mail.*;
import java.util.Stack;

public class MainApp extends Thread{
// private InetAddress myMachineAddress;
private Stack stk1;
private MainApp(String aStr) {
this.stk1 = new Stack();
}

public void run(){
System.out.println("Thread beginning");
try {
stk1.push((String)InetAddress.getLocalHost().getHostAddress());
System.out.println(stk1.peek());
}
catch (Exception ex) {
ex.printStackTrace();
System.exit(1);
}
while(true){
System.out.println("feedback IP ...");
try {
if((InetAddress.getLocalHost().getHostAddress()).equals((String)stk1.peek())){
System.out.println("The IP Address has no change");
System.out.println(InetAddress.getLocalHost().getHostAddress());
}
else{
stk1.push(InetAddress.getLocalHost().getHostAddress());
System.out.println(stk1.peek());
}
sleep(5000);
}
catch (Exception ex) {
ex.printStackTrace();
}
}
}

public static void main(String[] args){
try {
MainApp app = new MainApp();
app.start();
}
catch (Exception ex) {
ex.printStackTrace();
}
}
}

[hoxisoft]

看看这段代码：
import java.net.*;
public class NetTool{
InetAddress myIPaddress=null;
InetAddress myServer=null;

public static void main(String[] args){
NetTool mytool;
mytool=new NetTool();

System.out.println("Your host IP is:"+mytool.getMyIP());
System.out.println("The Server IP is:"+mytool.getServerIP());
}

public InetAddress getMyIP(){
try{
myIPaddress=InetAddress.getLocalHost();
}catch(UnknownHostException e){}
return (myIPaddress);
}
public InetAddress getServerIP(){
try{
myServer=InetAddress.getByName("www.abc.com");
}catch(UnknownHostException e){}
return (myServer);
}
}

[hk2000c]

我觉得不是取IP的代码有问题，因为我改IP之前程序能取到IP.但是改之后（线程仍在运行）程序不能捕获新的IP

[hk2000c]

试了，重新运行程序，就可获得。

[hoxisoft]

关于线程，我找了点资料，其中是不是因为这呢？？？说：“线程可以因为各种各样的原因终止并进入可运行状态（因为堵塞）。”
具体如下：

Thread Scheduling

In Java technology,threads are usually preemptive,but not necessarily Time-sliced(the process of giving each thread an equal amount of CPU time).It is common mistake to believe that "preemptive" is a fancy word for "does time-slicing".

For the runtime on a Solaris Operating Environment platform,Java technology does not preempt threads of the same priority.However,the runtime on Microsoft Windows platforms uses time-slicing,so it preempts threads of the same priority and even threads of higher priority.Preemption is not guaranteed;however,most JVM implementations result in behavior that appears to be strictly preemptive.Across JVM implementations,there is no absolute guarantee of preemption or time-slicing.The only guarantees lie in the coder’s use of wait and sleep.

The model of a preemptive scheduler is that many threads might be runnable,but only one thread is actually running.This thread continues to run until it ceases to be runnable or another thread of higher priority becomes runnable.In the latter case,the lower priority thread is preempted by the thread of higher priority,which gets a chance to run instead.

A thread might cease to runnable (that is,because blocked) for a variety of reasons.The thread’s code can execute a Thread.sleep() call,deliberately asking the thread to pause for a fixed period of time.The thread might have to wait to access a resource and cannot continue until that resource become available.

All thread that are runnable are kept in pools according to priority.When a blocked thread becomes runnable,it is placed back into the appropriate runnable pool.Threads from the highest priority nonempty pool are given CPU time.

The last sentence is worded loosed because:
(1) In most JVM implementations,priorities seem to work in a preemptive manner,although there is no guarantee that priorities have any meaning at all;
(2) Microsoft Window’s values affect thread behavior so that it is possible that a Java Priority 4 thread might be running,in spite of the fact that a runnable Java Priority 5 thread is waiting for the CPU.
In reality,many JVMs implement pool as queues,but this is not guaranteed hehavior.

翻译后的是：
在java技术中，线程通常是抢占式的而不需要时间片分配进程（分配给每个线程相等的cpu时间的进程）。一个经常犯的错误是认为“抢占”就是“分配时间片”。
在Solaris平台上的运行环境中，相同优先级的线程不能相互抢占对方的cpu时间。但是，在使用时间片的windows平台运行环境中，可以抢占相同甚至更高优先级的线程的cpu时间。抢占并不是绝对的，可是大多数的JVM的实现结果在行为上表现出了严格的抢占。纵观JVM的实现，并没有绝对的抢占或是时间片，而是依赖于编码者对wait和sleep这两个方法的使用。
抢占式调度模型就是许多线程属于可以运行状态（等待状态），但实际上只有一个线程在运行。该线程一直运行到它终止进入可运行状态（等待状态）或是另一个具有更高优先级的线程变成可运行状态。在后一种情况下，底优先级的线程被高优先级的线程抢占，高优先级的线程获得运行的机会。
线程可以因为各种各样的原因终止并进入可运行状态（因为堵塞）。例如，线程的代码可以在适当时候执行Thread.sleep()方法，故意让线程中止；线程可能为了访问资源而不得不等待直到该资源可用为止。
所有可运行的线程根据优先级保持在不同的池中。一旦被堵塞的线程进入可运行状态，它将会被放回适当的可运行池中。非空最高优先级的池中的线程将获得cpu时间。
最后一个句子是不精确的，因为：
（1）在大多数的JVM实现中，虽然不能保证说优先级有任何意义，但优先级看起来象是用抢占方式工作。
（2）微软windows的评价影响线程的行为，以至尽管一个处于可运行状态的优先级为5的java线程正在等待cpu时间，但是一个优先级为4的java线程却可能正在运行。
实际上，许多JVM用队列来实现池，但没有保证行为。

[hk2000c]

谢谢 hoxisoft(hoxisoft)，文章启发了我的一个想法。
改好IP后,重新 运行程序 能够获得新的IP地址

但是在运行期，则不能捕获改过的IP地址

是不是与java这个方法局限性有关呢？
JVM 把调用过的静态方法 存放入一个指定的内存中，以后再调用的话，执行方法就从这个内存段中取。如果一定要获得新的系统数据则要结束线程，再重起新线程。
不知我这样理解对不对。

[bsd]

我想这是InetAddress代码中的实现导致的这个问题
因为InetAddress中定义了一个
private static InetAddress localHost;
因此，不论什么时候用getLocalHost()取到的都是同一个对象（除非JVM重启）,返回的一直都是这个localHost，它并没有一个检测local host的ip变化的机制，所以在你的thread中是检查不出来的，但是你重新运行（此时，JVM重启，localHost重新生成一个新的对象）时就可以。

[hello_10000]

你用socket建立连接后再读取ip试试？

[bsd]

你可以通过取其他机子的ip佐证

[hk2000c]

help...

[hoxisoft]

照楼主的说法，程序重新运行应该能捕获新IP。。。试了吗