G*O
发帖数: 706 | | c*********n
发帖数: 128 | 2 这是Java著名的特点啊, 任何一本讲Jave的书一开始就会说
因为JVM会自动进行垃圾回收, 这样programmer写程序的时候就不用操心这方面的问题了
【在 G*O 的大作中提到】
: 这样的设计有什么优缺点？
: 谢谢！
| c*****t
发帖数: 1879 | 3 http://en.wikipedia.org/wiki/Destructor_%28computer_science%29
and
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
GC takes care of the biggest pain, the memory management. But by
taking away destructor, one also loses an important pattern for
resource management. | m******d
发帖数: 3243 | | m******t
发帖数: 2416 | 5
(I have some vague memory this came up here before.)
With the GC in place, no longer is the destruction of an instance
predictable to the programmer. So any timing-sensitive "resource management"
can't be done in a destructor (or "finalizer" as in Java) anyway. Some kind
of non-standard destroy/release/shutdown method would have to be defined on
a per-class basis.
I see it more as some price paid for all the benefits of GC brings, but not
a loss of any pattern - as long as a pattern can be easi
【在 c*****t 的大作中提到】
: http://en.wikipedia.org/wiki/Destructor_%28computer_science%29
: and
: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
: GC takes care of the biggest pain, the memory management. But by
: taking away destructor, one also loses an important pattern for
: resource management.
| g*****g
发帖数: 34805 | 6 The Object's finalize method should be avoided.
The time that it will be called is unpredictable,
that alone will give you more hassles than benefits.
There's no timing-sensitive "resource management", we count on
VM to take care of it. If you have a critical application where
response time for every single operation has a bound to be guranteed
and the bound is tight, then Java is not for you.
For that sense, if you are operating a robot on the Moon from the Earth
and every ms delay could put do
【在 m******t 的大作中提到】
:
: (I have some vague memory this came up here before.)
: With the GC in place, no longer is the destruction of an instance
: predictable to the programmer. So any timing-sensitive "resource management"
: can't be done in a destructor (or "finalizer" as in Java) anyway. Some kind
: of non-standard destroy/release/shutdown method would have to be defined on
: a per-class basis.
: I see it more as some price paid for all the benefits of GC brings, but not
: a loss of any pattern - as long as a pattern can be easi
| m******t
发帖数: 2416 | 7 By "timing-sensitive resource management" I was referring to things like
releasing a connection. Those are the things you can't afford to wait for
finalizer.
【在 g*****g 的大作中提到】
: The Object's finalize method should be avoided.
: The time that it will be called is unpredictable,
: that alone will give you more hassles than benefits.
: There's no timing-sensitive "resource management", we count on
: VM to take care of it. If you have a critical application where
: response time for every single operation has a bound to be guranteed
: and the bound is tight, then Java is not for you.
: For that sense, if you are operating a robot on the Moon from the Earth
: and every ms delay could put do
| O*******d
发帖数: 20343 | | G*O
发帖数: 706 | 9 用Dispose interface怎么样？
thanks.
【在 g*****g 的大作中提到】
: The Object's finalize method should be avoided.
: The time that it will be called is unpredictable,
: that alone will give you more hassles than benefits.
: There's no timing-sensitive "resource management", we count on
: VM to take care of it. If you have a critical application where
: response time for every single operation has a bound to be guranteed
: and the bound is tight, then Java is not for you.
: For that sense, if you are operating a robot on the Moon from the Earth
: and every ms delay could put do
| m******t
发帖数: 2416 | 10
It's really not GC that's causing more memory to be used, but rather the
fact that the JVM never returns any memory to the OS, even after the memory
is GC'ed within the VM.
【在 O*******d 的大作中提到】
: 优点不用说了,缺点之一就是用memory很多.
|
|
