Jython relies on the Java runtime so the JVM’s garbage collector is used. This difference can cause some subtle porting problems if your Python code depends on the behavior of the reference counting implementation.

Sometimes objects get stuck in tracebacks temporarily and hence are not deallocated when you might expect. Clear the tracebacks with:

import sys
sys.exc_clear()
sys.exc_traceback = sys.last_traceback = None

Tracebacks are used for reporting errors, implementing debuggers and related things. They contain a portion of the program state extracted during the handling of an exception (usually the most recent exception).

In the absence of circularities and tracebacks, Python programs need not explicitly manage memory.

Why doesn’t Python use a more traditional garbage collection scheme? For one thing, this is not a C standard feature and hence it’s not portable. (Yes, we know about the Boehm GC library. It has bits of assembler code for most common platforms, not for all of them, and although it is mostly transparent, it isn’t completely transparent; patches are required to get Python to work with it.)

Traditional GC also becomes a problem when Python is embedded into other applications. While in a standalone Python it’s fine to replace the standard malloc() and free() with versions provided by the GC library, an application embedding Python may want to have its own substitute for malloc() and free(), and may not want Python’s. Right now, Python works with anything that implements malloc() and free() properly.

In Jython, the following code (which is fine in CPython) will probably run out of file descriptors long before it runs out of memory:

for file in <very long list of files>:
f = open(file)
c = f.read(1)

Using the current reference counting and destructor scheme, each new assignment to f closes the previous file. Using GC, this is not guaranteed. If you want to write code that will work with any Python implementation, you should explicitly close the file; this will work regardless of GC:

for file in <very long list of files>:
f = open(file)
c = f.read(1)
f.close()

if ( __name__ == "__main__" ):
    test()
    while ( True ):
        time.sleep( 1 )
观察mem:内存维持不变! 

从这点可以猜测:python不是立即释放资源的.

个人测试代码:
-----------------------------------------------test0.py-------------------------------------

import time

def test():
    for i in range ( 1000000 * 10 ):
        del i

def test_2():
    #i = range ( 1000000 * 10 )
    #del i
    pass

def test_3():
    #i = "*" * ( 1000000 * 10 )
    #del i
    pass

if ( __name__ == "__main__" ):
    for i in range( 10 ):
        test()
        test_2()
        test_3()
        time.sleep( 1 )
    while ( True ):
        time.sleep( 1 )
-----------------------------------------------------test0.py-------------------------------------- 

运行 python test0.py

"while ( True ):
        time.sleep( 1 )
 "
保证python不退出.

发现python的内存占用率为60%.

如何解决这个问题呢?看下面的:

-----------------------------------------------test1.py-------------------------------------

#coding=utf-8
import time

max_number = 1000000 * 10
def test_0():
    for i in range ( max_number ):
        del i

def test_1():
    for i in range( 1000 ):
        for i in range ( max_number / 1000 ):
            del i

if ( __name__ == "__main__" ):
    #test_0()#内存使用率占40%
    test_1()#内存使用率占0.2%
 
    print "---------------------"
    while ( True ):
        time.sleep( 1 )

-----------------------------------------------test1.py-------------------------------------

 我想问题:问题也许解决了.

这就要看你的实际需求是什么了.

例如:

我做过一个爬虫程序,如果不断往这个线程里面传递url,那么这个线程不到一会就挂了.我的改进方法:就是控制这线程能够接受的url队列长度.以及其他的优化.
 其实这个不是循环导致的内存被python持有,而是range( n )让python分配了很多的内存.退出test(),python回收内存,但是python并不释放了,而是让pool持有内存空间.

>>> li = ['a', 'b']

>>> li = li + ['example', 'new'] 

>>> li

['a', 'b', 'example', 'new']

>>> li += ['two']              

>>> li

['a', 'b', 'example', 'new', 'two']

>>> li = [1, 2] * 3      

>>> li

[1, 2, 1, 2, 1, 2]