最近因为搞Android开发，开始涉足Java编程。Android的Activity（类似于一个窗体，但是实际上代表一个屏幕而不是视图）是这样调用的，当你打开一个程序，它的onCreate函数会被调用，应用程序加载视图，初始化工作一般在这里做。当你点击了后退键，应用程序并不退出，但是你看到的应用程序屏幕会隐藏。然后当你再次点击应用程序的时候，onCreate还会被调用，也就是说视图要重新加载一次，所有的初始化工作要在做一次。所有的Android程序都是这么设计的，视图不断的被加载，我不知道它们是否在后台被销毁，原则上应该是。但是事实上，要看是什么对象，如果你在初始化的时候启动了一个线程，而在onDestroy里没有终止它（问题是终止一个线程是很麻烦的），那么你每打开一次应用程序，就会启动一个新的线程，而老的线程实际上还在运行，虽然你已经失去对它的所有控制权，因为对象的指针都指向了新的线程。我甚至做过测试，在线程里保存一个界面的对象比如某个Button，然后重复加载，用Static变量保存这个button，然后，下次启动，你会发现，它并没有被销毁。我当时很困惑，也就是大家这种通常的做法，实际上对象并没有删除，只不过我们没有了它的指针，所有变量对象都指向了新的对象，除非它是个static类型的。后来我觉得我的担心是不必要的，虽然那些对象不一定被销毁，但是后台总是会处理的，java知道那些对象我们还在引用，那些已经不在引用，它会自动清理。问题是至少线程这种对象，它是不会自动销毁的，也就是说我们必须手动处理它。Java的自动化意义何在，这不就是C++的内存泄漏吗？我们不得不区分哪些对象是会自动销毁，哪些是不会自动销毁的，比C++还要麻烦，C++所有的new都有delete，非常明确。
Java自动回收的是指对象之类的东西，线程里创建的对象也回收，但是资源没有。
C++对象都实现了，File对象销毁，资源自动释放，Java为什么不实现。还有数据库，我觉得C++的析构和构造函数这模式是所有编程语言里最精华的部分，Java有构造，没析构（它的机制无法实现这一点，不能确定析构什么时候调用），完全把这种优美破坏掉了，不得不手动清理，不是每个对象都有onDestroy。
其次，任何语言都有其优缺点，Java这种垃圾回收的机制就是让开发人员不去直接关注和管理内存分配这块，如果你认为这是丑陋，那他确实是丑陋。
另外，内存泄漏这个东西是指的内存不断被占，但是无法回收的情况吧，你也提到了，VM会知道那些对象有用，那些对象都取不到了，所以这个和内存泄漏不是一回事。
至于static这个东西，你还是需要多了解Java一下了...
在Windows下的控制台程序是运行在一个虚拟机上的，一旦程序结束，无论是否是正常结束，系统都会撤销该虚拟机，并回收资源，因此不会有内存泄漏的问题。（注意这是操作系统的功能，与C++无关，另外如果内存使用问题严重，运行时就当机了~~）
如果是Win下边的应用程序就难说了，有可能有未释放的资源，只有等到重启系统了。
http://wenwen.soso.com/z/q122347255.htm
不过看着用java写的代码还是觉得顶好看的
你只要让jvm明白这个线程的生命周期到了
楼上说了android不能代表java
你可以质疑现有的android的习惯或方式
但是java本身是可以为你提供解决方案的
这个说法好像有点问题，如果在C++里，程序是正常结束，程序本身就会释放对系统资源的占用。只有C++程序出现异常，才会由OS接管进行资源释放。
在JAVA里也一样，碰到RuntimeError或RuntimeException，JVM也会释放原来占用的资源。
因为他的目的并非美妙
但是说丑陋我觉得有点过了
要说丑陋
basic是挺丑陋的
在C++里 delete只是针对Heap上的资源释放而设置的，stack里的资源本身就是由系统管理的。如果出现异常后，用户又没在异常处理中写delete。造成泄漏最终导致崩溃的话。系统就会接管这些资源，进行释放。仅对windows系统，unix的不是很懂。
Java之所以有今日之成就，更多的是与各个活跃的社区有关。解决任何方面的问题，你都能找到开源的（而且通常是很不错，甚至是最好的）Java实现。因为目前的Java类库、框架很多，也很不错，而且基本都是开源实现，因此，在新开发的项目上，选择Java的可能性必然会多，吸引更多开发者使用Java或者知道Java，反过来，这些规模庞大的开发者，又各自开发了新的类库、框架。这形成了一个良性循环。在语言的生态环境而言，目前没有其他语言能出其右者。
C++不把closeHandle()写到析构里，File关闭不了。
Java里不显式的调用close(),File一样关闭不了。
没看出，他们有什么区别来。
1、没有任何有效的变量会引用到这个对象
2、这个对象不是正在运行的线程对象楼主把一个对象的引用保存在一个 static 变量里，它是一直不会被回收的
Java里不显式的调用close(),File一样关闭不了。
===================================================
C++的File（其实在不同的类库里名称是不同的），一般是一个写好的类，不是用户每次使用都去写自己的一个File类。那么使用的时候就不必管Close这样的事了。Java也是一个写好的类，而且是内部的不是Java语言写的。Java语言的语法限制它不能自动的关闭，因为那是不可控的。
其实 java 自动回收的是对象所占用的内存，其它的资源，比如打开的文件、socket 之类的是不会自动关闭的。从另一个角度看，一个文件如果已经被关闭，但是如果这个文件流依然被一个变量引用，则这个流也是不会被回收的：
class Cls{
private static FileInputStream fis = null;
static Exception{
try{
fis = new FileInputStream("d:\\aa.txt");
fis.close();
}catch(Exception ex){
ex.printStacktrace();
}
}
}
如果不执行 fis = null; 则虽然已经关闭了 fis，但是如果有个变量一直引用到这个文件流，则这个文件流对象还会一直存在内存中。
话说有一本很有名的书Thinking In Java，想借用TIJ的书名来说明我的观点。就好象学习英语一样，学英语，到一定程度后，就应当尽量用英语或者英美人的习惯来思考。
自然语言如是，程序语言亦如是
发现咱中国人总是缺少一种包容的姿态去看待问题，在还未真正了解的情况下就急于批判，去否认。
在你批判它之前，你先要想几个问题：
1、他如果真那么遭，为什么那么多人在用？到底是那么多人错了，还是你错了，众人皆醉你独醒么，ORACLE,GOOGLE,IBM以及那么多大公司支持它，它要真那么垃圾，难道那些大公司有病？
2、一个东西是否优雅，都是从一个理解的角度去评审的，就像梵高的抽象派艺术，在当时无人理解，但是后世却被评为价值珍贵艺术流派。
3、楼主，你对于不理解的东西，不应该保持排斥与对立的态度，如果你对它感到困惑，应该尽量去弄懂它，理解它，等你真正知道它以后，你才会知道它的优势，它的优雅。
首先你要知道,为什么C++要有析构函数?这不是C++的一个先进设计,这是C++的一个不得以而为之的设计.怎么理解,想像一下要是没有析构函数,因为C++的内存的使用都要手动的释放所以每一个对象都要有close,destory,delate等等的函数,来释放内存,为了方便所以统一设计了一个析构函数,可以少定义上述函数,但是很多时候析构函数是不能胜任释放内存的,因为对象本身可能会创建并引用另外的对象,而这个对象的生命周期不一定和创建者同步,所以还是得引入很多close,destory,delate等等的函数.而真正析构函数所能做的java的GC都能很好的做好.正如楼主所说"担心忘了调用Close",同样你就不担心把close忘写在析构函数里吗?同样如果你不会忘了把close写在析构函数里那么同样不会忘记在类的最后写上close.
当然你要是扯上文件操作以外的普通对象那简直就是在欺负C++.
Java的GC机制是只要某个对象没有引用指向它,它就能被回收,一般局域的对象运行完了在内存里就是孤立的了,JVM就能回收它,这基本也是析构函数的办法,在C++运行完局域代码的最后时刻,系统就知道了,这是指向这个对象最后的指针了,所以就释放该对象,但是这是最美好的情况,有时候局域代码会开辟新的内存,并且把引用传出来,这时析构函数就无能为力,这就需要大家在上级代码中去实现释放了,很多时候这就是内存泄漏的隐患了因为调用你局域代码的人往往就忘了你其实给他新开辟了内存,而一旦他把记录引用的变量重新赋值,那么意味着那个内存已经被永远的遗忘了.而JVM的GC则要安全的多,因为只要传出来引用被另外赋值,那么GC就能发现这块孤立的内存,从而给别人使用,当然你要是还引用着就特别是像你那样一个static你让JVM怎么给你回收,这就好像你把苹果抱在怀里却嚷嚷着怎么别人不把苹果拿去.
一般Java里面除非必要,否则很少用static的.
相比其他手机API框架，Android也算是很好用的了。
但是相比PC上的框架还显稚嫩，实现多项目可重用的控件比较麻烦，Activity是个很恶心的设计，很容易内存泄露。
但是这些并不是Java的问题。
个人觉得面向对象语言中最优雅的就算java了
看来你还是固守着底层为王的思想,我想问一下什么是程序员的基本权利?
是对内存的完全控制吗?如果这样你天天malloc或new 然后free或delate去,什么时候不爽了就去做一下.
你不觉得这样的是程序员吗?真正的程序员归根到底是用智慧去构建程序的,而不是为了控制计算机的,比如你看着你的程序CPU占用100%,你会很高兴吗?当然不是,我们看的是我们的程序是否实现了我们的想法,对不?
不可否认GC确实不能做到实时关闭释放资源,但是一般应用程序没有这个要求,内存不够了,GC在一秒钟之内就能释放足够的内存(如果有的话),而一般应用程序都没有如此之高的实时性要求,包括很多系统级的应用,当然你要牵扯操作系统层,驱动级别的实时性要求,没人会用Java写这些程序.至于Android上的,呵呵,说句真话我也不知道适不适合,以目前的硬件配置很悬,但是以后有更强大的硬件就不好说了.
总之GC能让你更专注与程序的功能和代码的架构这是一个非常重大的进步.
看来你还是固守着底层为王的思想,我想问一下什么是程序员的基本权利?
是对内存的完全控制吗?如果这样你天天malloc或new 然后free或delate去,什么时候不爽了就去做一下.
你不觉得这样的是程序员吗?真正的程序员归根到底是用智慧去构建程序的,而不是为了控制计算机的,比如你看着你的程序CPU占用100%,你会很高兴吗?当然不是,我们看的是我们的程序是否实现了我们的想法,对不?
不可否认GC确实不能做到实时关闭释放资源,但是一般应用程序没有这个要求,内存不够了,GC在一秒钟之内就能释放足够的内存(如果有的话),而一般应用程序都没有如此之高的实时性要求,包括很多系统级的应用,当然你要牵扯操作系统层,驱动级别的实时性要求,没人会用Java写这些程序.至于Android上的,呵呵,说句真话我也不知道适不适合,以目前的硬件配置很悬,但是以后有更强大的硬件就不好说了.
总之GC能让你更专注与程序的功能和代码的架构这是一个非常重大的进步.
看来你还是固守着底层为王的思想,我想问一下什么是程序员的基本权利?
是对内存的完全控制吗?如果这样你天天malloc或new 然后free或delate去,什么时候不爽了就去做一下.
你不觉得这样的是程序员吗?真正的程序员归根到底是用智慧去构建程序的,而不是为了控制计算机的,比如你看着你的程序CPU占用100%,你会很高兴吗?当然不是,我们看的是我们的程序是否实现了我们的想法,对不?
不可否认GC确实不能做到实时关闭释放资源,但是一般应用程序没有这个要求,内存不够了,GC在一秒钟之内就能释放足够的内存(如果有的话),而一般应用程序都没有如此之高的实时性要求,包括很多系统级的应用,当然你要牵扯操作系统层,驱动级别的实时性要求,没人会用Java写这些程序.至于Android上的,呵呵,说句真话我也不知道适不适合,以目前的硬件配置很悬,但是以后有更强大的硬件就不好说了.
总之GC能让你更专注与程序的功能和代码的架构这是一个非常重大的进步.
我没有反对使用GC的意思，更没有强调使用底层操作的编程，只是GC能力有限，却又没有提供机会让程序员处理。能够进行底层操作，并不是需要您天天malloc或new .如果GC设计得好，实时释放内存并非不可能。（欢迎到我的博文看看：http://blog/csdn.net/tongshou/, 我在一种语言引擎中实现了实时释放内存、句柄等的GC），目前的GC并没有能力让程序员完全安心于程序逻辑、专心解决问题。GC引起的问题，往往让最终用户去承当！
http://blog.csdn.net/tongshou/
虽然java 作为一门工程性语言，他有很多功能难以实现，不过它很多方面是安全的，至少对大众型开发人员来说是这样，因为即使出现问题，很多时候问题会变得明显，因为开发人员触及的层面小。
而且，我最后也不得不羞愧得说一句，中国人大众的编程水平，实在是让人焦虑，现今毕业大学生的素质也让人汗颜，就连简单的java他们都难以把握，你还放心让他们去开发C++么？我个人觉得java语言应该是最适合中国国情的，中国大量廉价劳动力加上素质低下的员工，没有java很难想象中国的IT业是个什么样子，还有java那充斥着免费、跨平台和开源，如果没有这些，很难想象IT在中国市场有多少存活率，如果要你开发C++，你愿意去买一套正版的VS么？当然也有免费的方式vim+gcc 但是那时linux专属的，在这个充斥着windows的国家，不太现实(java的跨平台解决这个问题，我们可以在免费的平台上开发，然后发布到收费的平台上)。
不要跟我说盗版，我认为盗版将成为我国IT事业最大的阻碍，虽然我说不出什么硬道理，不过我有这种预感。
说句真话程序员希望时刻想着CPU指令,内存控制吗?不想啊,程序员最希望的是专注于自己的程序设计,但是实际情况是程序员不得不去思考这些问题,所以与其说是内存控制的权利不如说是内存控制的烦恼.对不?
你说的"实现了实时释放内存、句柄等的GC",如果仅仅是像你说的"在拥有句柄的变量/结点的作用域失效时、或数值要被覆盖时，自动关闭或释放这些句柄"和普通GC有什么区别?增加了释放句柄的功能吗?还有你的这种实时性和Java的GC有任何区别吗?
顺便提一句JVM的GC不是很快释放内存是为了在内存充足的情况下充分利用内存,只有在内存紧张的情况下才会去耗费CPU时间释放内存.
不可否认JVM的GC是不完美的,但是他已经可以大大减少内存泄漏了,特别是很少有C++中经常会出现的陷阱似的内存泄漏.对一个Java程序员具备一些常识性的习惯就可以很好的管理内存这已经是很大的提高了,至于为了达到完全的完美而耗费的数倍精力很多时候也似乎是多余的.所以目前来看JVM的GC基本是够用的.
Ruby和Python的出现都早于JavaJava只是C++的简化版。
我所说的那个GC与JAVA的GC，既有相同的地方，也有很大的不同，就是实时可控制性。实时可控的一个好处是让可用内存最大化，另外一个好处是分散回收内存，不太可能引起电脑停滞现象。实时可控在不同场合作用和意义可能会不同。现在电脑的内存比较多，但是，每一块的内存仍然都是宝贵的，如果内存不及时回收，还是容易耗尽的。JAVA有GC自动回收内存体系，JAVA编程不用关心内存来去问题，无形中容易让程序员不懂得如何珍惜内存，好象对JAVA来说，内存总不是个问题，有问题时JAVA本身会顶着！
java的GC一边是需要的时候再做。这个本身并没有错。
对于一段程序，你希望他先出结果。还是一直实时释放不需要的内存？
如果是单片机的话。我错了。
PS:IC现在大多都是java的了
public int getAdjacent(List <Integer>list,int x);用list集合里面的元素值跟x比较，首先取单个元素计较，再取两个元素相加比较，直到N个元素相加比较，最后返回最接近x的数，这个最接近x的数必须比x小，也就是单个比较的话首先先去掉大于x的元素再比较 ，如此类推，直到N个相加输去掉大于X的数再比较如:List xlist = new ArrayList();
for(int i=0;i<list.size();i++)
{
if(list.get(i)<x)
{
xlist.add(list.get(i))
}
}最后用xlist元素的值跟x比较，并把返回的最接近X的值放入最接近X的set中， 如此类推 直到第N个元素相加最接近X的值放入set中，此时set中保存的是由单个元素到N个元素相加最接近X的值，再用set值去比较 最终返回 最最接近X的值组合，我想要的并不是一个最接近的数 ，我想要的是 所有数递归起来加起来 最接近比较值的数。假如我的集合里面有1,2,3,6,7,11,100,200,33,31 比较值是50 我想要的是33、7、6、2、1 这个组合加起来是最接近50的 当然也有别的组合 ，其实最接近比较数并且不大于比较数 那就是比较数-1了 这样就要返回 集合里面的所有等于比较值-1的组合 这个组合就是我想要的 http://topic.csdn.net/u/20110820/21/eb866f36-e1ac-4ac9-b302-b87983e9d5c3.html 欢迎大家来回帖
实事的情况是现在有大量的程序是费尽心思把内存作为cache,来加快各种应用,而不是那个任务管理器里面苍白的数字.
你如果Linux用的多的话你会很明显感觉到怎么Linux的空余内存怎么总是那么少,因为Linux里设计了大量的系统cache,当然当你需要开辟内存时,这些cache又会释放出来给更重要的用途,你觉得这样不好吗?这样不就是最大化利用硬件资源吗?
"不及时回收，还是容易耗尽的"你的这话很明显的显示你对JVM的GC不了解,不马上回收不意味着不回收,回收内存是要占用CPU时间的,不管你是手动的free,delate方式还是任何GC,当没必要去占用CPU时间来把这部分内存变成任务管理器上的数字的话你不觉得很多余吗,当内存紧张时JVM的GC会很快释放出内存,何来耗尽之说?!
你虽然没说"底层为王"的话,但是你的潜意识里已经告诉我们在你心里肯定是越玩底层的人水平越高.无论是你对直接内存控制的欲望还是对GC的不信任.当然很多人以底层为乐,也有更多的人乐于追求底层以上的抽象层.我也不想对此评论,各取所需,求同存异吧.
"往往只顾 “提高编程效率，降低生成成本”，很少考虑最终用户可能面对的问题"之于这话我着实不敢苟同.可以这么说吧,不降低成本何来用户?你的生产成本高还不是用户买单,当用户要考虑价格和性能的时候你就知道降低成本有多大的作用了.关于用户可能面对的问题我也想说一下,如果说C,C++是100的努力获得100的成果的话,Java就是50的努力获得95的成果,诚然95的成果是低于100的,但是减少一半的成本用户是非常乐意接受的.而实际是Java到底和C++相比能省下多少的成本这个也许对数百行代码的程序两者根本没区别,但是到上万行,十万行的基本差距就大了,都已经超过2倍了,之间的成本很有可能是数量级的差别.要在这两者之间选择傻子都明白该怎么做,更何况是精明的用户呢.
之于你认为的"不是程序语言本身的问题，而是人的问题"就显得太天真了.你真的以为一个几百人参与的项目能所有人都在一个很高的水平线上,你就能排除没有一个水平差劲的程序员,哪怕是水平极高的程序员你就不担心什么时候他也会犯错,而且错的不知不觉,只要有一个人没做到完美对于C++的项目就很有可能造成极大的破坏,而这些就是Java这类语言试图避免的,语言之间对于具体应用上还是有差别的.不要把人想得太完美,人毕竟不是机器人,人总是会出这样那样的错误,尽量去减少人出错的机会还是比要求人减少错误的可行性更高.
String comm = "perl /var/www/extsuite/extman/tools/userctl.pl--mod=add -username="+uname +"-password="+pass;
runLinuxCmd(String cmd) //本类调用public String runLinuxCmd(String cmd) {
BufferedReader bf = null;
try {
Process process = Runtime.getRuntime().exec(cmd);
bf = new BufferedReader(new InputStreamReader(process.getInputStream()));
String line = "";
String resutl="";
while ((line = bf.readLine()) != null) {
resutl =resutl+ line.trim()+"\n";
}
System.out.println("---------------try result------------------"+resutl);
return resutl;
} catch (java.io.IOException e) {
e.printStackTrace();
System.out.println("------------error--------------");
return null;
} finally {
if (bf != null) {
try {
bf.close();
bf = null;
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}}单独在shell环境下执行perl命令是没有问题，能够插入数据。 我在网上看到有人讲过把perl命令写进sh脚本就可以了，我也不知道这是为什么按理说java能够调用shell命令也能调用perl脚本命令。非要包装一下的话我也写了一个shell脚本单独运行shell脚本也能添加数据就是java调用又没有添加数据了 我想要的是验证过的结果 大道理就不用讲了直接来真工夫啊 我写的shell脚本代码如下:#!/bin/sh
perl /var/www/extsuite/extman/tools/userctl.pl--mod=add -username="$1" -password="$2";这个做了两天都没有做好 如果能有满意的结果我会加分的谢谢大家 欢迎大家来这里回帖http://topic.csdn.net/u/20110821/20/ae1e4815-1c81-4c75-88ae-db263128f963.html?61772
sun的jvm设计者认为，过于实时的回收对象，本身对执行性能是一个较大的影响，因为每个对象的回收也是要损耗性能的，因此sun的gc实现，会监控系统和进程的使用情况，在某个空闲的时候去回收内存(不一定要内存满了再回收)，而且有时候创建对象的量也是巨大的，如果某个时刻大量回收内存，对于CPU的压力是很大的。当然，内存满了的时候去回收掉所有多余对象，本身也是很消耗性能的，所以sun所实现的gc的方式，并不是在满了的时候去回收掉所有的无引用对象，而是回收掉一部分，已足够新的对象有内存空间供食用，一般会被快速回收掉的对象是那些年轻对象，就是刚刚建立不久，而又未重复使用或者较少重复使用的对象，而那些使用时间较长的老对象，则可能会在很长的一段时间后才会被回收。
其实sun的gc实现是很科学的。
真正懂Java的人都清楚Java的缺点在哪,当然也知道Java的优点在哪,我已经不知几次承认Java的GC不是完美的了,但是如果你要说Java的GC是垃圾之类的,你个人可以去这么认为,我无权反对,但是正如spiniper所说,Java的GC还是很科学的.至于你说的那种GC说句不客气的话和C++没有GC没有区别.我实在不明白是谁"飘飘然陶醉于自我".
再跟你说几句,什么叫实时释放直接的内存?你new了,然后你delate了,内存就释放了,这他妈才叫实时释放,你非要"在拥有句柄的变量/结点的作用域失效时"才释放和Java的GC有什么区别?但是为什么Java的GC不是立马释放呢,那不是释放不了,那是那时释放占用CPU时间,影响性能,所以晚点释放.这他妈叫优化知道不,说得简单点这叫对你那种简单GC的改进知道不?理解不?
你要是再不理解我真的只能引用Squall1009的话了:"冬虫不可语夏".
tongshou 老兄和我有不谋而合之处。＝＝＝＝＝＝Forcal是一种嵌入式脚本，采用自动垃圾回收与手动垃圾回收并存可简化脚本使用、扩大脚本使用范围并提高混合编程效率和运行效率。设主程序语言为C/C++或delphi等，主程序中有一个对象（或结构等）A，要实现在主程序和Forcal脚本中对A的联合操作。首先，要使主程序和Forcal都能操作对象A，对象A必须注册到Forcal系统中，可注册为两类对象，一种注册对象可被垃圾收集器回收，另一类注册对象垃圾收集器无法回收。此外，还要向Forcal注册一些操作对象A的函数。有以下多种联合操作方式：1、注册为垃圾收集器无法回收的对象，基本特点为：主程序可生成对象A并注册到Forcal系统，对象A也可在脚本中由专用函数生成；
主程序可销毁对象A，Forcal脚本中也可销毁对象A，销毁可以是立即进行的，或者暂存到缓冲池中；
主程序或脚本中都可一次销毁对象A的所有实例；
主程序或Forcal脚本用户没有销毁的实例由Forcal系统最终回收。2、注册为垃圾收集器可回收的对象，基本特点为：主程序可生成对象A并注册到Forcal系统，对象A也可在脚本中由专用函数生成；
主程序可销毁对象A，Forcal脚本中也可销毁对象A，销毁可以是立即进行的，或者暂存到缓冲池中；
主程序或脚本中都可一次销毁对象A的所有实例；
主程序或Forcal脚本用户没有销毁的实例由Forcal系统最终回收。主程序可按一定规则启动垃圾收集器回收垃圾对象；
Forcal脚本中可立即启动垃圾收集器回收垃圾对象；
主程序可设置垃圾收集器不能启动，则脚本中的垃圾收集器也无法运行。注：Forcal垃圾收集器采用标记清除算法。3、多种对象并存时，有些对象注册为垃圾收集器可回收的对象，有些对象注册为垃圾收集器不可回收的对象，各自具备各自的特点，不相互影响。由于自动垃圾回收与手动垃圾回收并存，故无论在主程序，还是在Forcal脚本中销毁一个对象，不必担心会带来任何问题。而只采用自动垃圾回收的脚本系统，在实现复杂功能时，主程序和脚本系统接口上需费很多心思，往往会费力不讨好。个人认为，自动垃圾回收与手动垃圾回收并存的脚本系统，至少在混合编程方面，最终会获得用户的认可。参考：http://topic.csdn.net/u/20110816/19/f0eab6c1-88ce-4d11-a957-da1d9f7cdb58.html?83748欢迎访问：http://www.forcal.net/
java有那么多特性，你精通了多少个？一开口就java是丑陋的语言。