Object creation & lifetime One critical issue when working with objects is the way they are created and destroyed。 Each object requires resources, most notably memory, in order to exist。 When an object is no longer needed it must be cleaned up so that these resources are released for reuse。 In simple programming situations the question of how an object is cleaned up doesn’t seem too challenging: You create the object, use it for as long as it’s needed, and then it should be destroyed。 However, it’s not hard to encounter situations that are more complex。  77681

Suppose, for example, you are designing a system to manage air traffic for an airport。 At first it seems simple: Make a container to hold airplanes, then create a new airplane and place it in the container for each airplane that enters the air-trafficcontrol zone。 For cleanup, simply clean up the appropriate airplane object when a plane leaves the zone。 

But perhaps you have some other system to record data about the planes; perhaps data that doesn’t require such immediate attention as the main controller function。 Maybe it’s a record of the flight plans of all the small planes that leave the airport。 So you have a second container of small planes, and whenever you create a plane object you also put it in this second container if it’s a small plane。 Then some background process performs operations on the objects in this container during idle moments。 

Now the problem is more difficult: How can you possibly know when to destroy the objects? When you’re done with the object, some other part of the system might not be。 This same problem can arise in a number of other situations, and in programming systems (such as C++) in which you must explicitly delete an object when you’re done with it this can become quite complex。 Where is the data for an object and how is the lifetime of the object controlled? C++ takes the approach that control of efficiency is the most important issue, so it gives the programmer a choice。 For maximum runtime speed, the storage and lifetime can be determined while the program is being written, by placing the objects on the stack (these are sometimes called automatic or scoped variables) or in the static storage area。 This places a priority on the speed of storage allocation and release, and this control can be very valuable in some situations。 However, you sacrifice flexibility because you must know the exact quantity, lifetime, and type of objects while you’re writing the program。 If you are trying to solve a more general problem such as computer-aided design, warehouse management, or air-traffic control, this is too restrictive。 

The second approach is to create objects dynamically in a pool of memory called the heap。 In this approach, you don’t know until run time how many objects you need, what their lifetime is, or what their exact type is。 Those are determined at the spur of the moment while the program is running。 If you need a new object, you simply make it on the heap at the point that you need it。 Because the storage is managed dynamically, at run time, the amount of time required to allocate storage on the heap can be noticeably longer than the time to create storage on the stack。 Creating storage on the stack is often a single assembly instruction to move the stack pointer down and another to move it back up。 The time to create heap storage depends on the design of the storage mechanism。 

The dynamic approach makes the generally logical assumption that objects tend to be complicated, so the extra overhead of finding storage and releasing that storage will not have an important impact on the creation of an object。 In addition, the greater flexibility is essential to solve the general programming problem。  论文网

Java uses dynamic memory allocation, exclusively。7 Every time you want to create an object, you use the new operator to build a dynamic instance of that object。