java programming unleashed [ EN ], Java2

[ Pobierz całość w formacie PDF ]
.Using threads, you can have lots of applets running at once on the same page.Depending on how many you have, you may eventually exhaust the system so that all of them will run slower, but all of them will run independently.Even if you don't have lots of applets, using threads in your applets is good Java programming practice.The general rule of thumb for well-behaved applets: Whenever you have any bit of processing that is likely to continue for a long time (such as an animation loop, or a bit of code that takes a long time to execute), put it in a thread.Writing Applets with ThreadsHow do you create an applet that uses threads? There are several things you need to do.Fortunately, none of them are difficult, and a lot of the basics of using threads in applets is just boilerplate code that you can copy and paste from one applet to another.Because it's so easy, there's almost no reason not to use threads in your applets, given the benefits.There are four modifications you need to make to create an applet that uses threads:lChange the signature of your applet class to include the words implements Runnable.llInclude an instance variable to hold this applet's thread.llModify your start() method to do nothing but spawn a thread and start it running.llCreate a run() method that contains the actual code that starts your applet running.lThe first change is to the first line of your class definition.You've already got something like this:public class MyAppletClass extends java.applet.Applet {.}You need to change it to the following :public class MyAppletClass extends java.applet.Applet implements Runnable {.}What does this do? It includes support for the Runnable interface in your applet.Interfaces, as discussed in Chapter 14, “Classes, Packages, and Interfaces,” are a way to collect method names common to different classes, which can then be mixed in and implemented inside different classes that need to implement that behavior.Here, the Runnable interface includes the behavior your applet needs to run a thread; in particular, it gives you a default definition for the run() method.The second step is to add an instance variable to hold this applet's thread.Call it anything you like; it's a variable of the type Thread (Thread is a class in java.lang, so you don't have to import it):Thread runner;Third, add a start() method or modify the existing one so that it does nothing but create a new thread and start it running.Here's a typical example of a start() method:public void start() { if (runner == null); { runner = new Thread(this); runner.start(); } }If you modify start() to do nothing but spawn a thread, where does the body of your applet go? It goes into a new method, run(), which looks like this:public void run() { // what your applet actually does}run() can contain anything you want to run in the separate thread: initialization code, the actual loop for your applet, or anything else that needs to run in its own thread.You also can create new objects and call methods from inside run(), and they'll also run inside that thread.The run method is the real heart of your applet.Finally, now that you've got threads running and a start method to start them, you should add a stop() method to suspend execution of that thread (and therefore whatever the applet is doing at the time) when the reader leaves the page.stop(), like start(), is usually something along these lines:public void stop() { if (runner != null) { runner.stop(); runner = null; } }The stop() method here does two things: it stops the thread from executing and also sets the thread's variable (runner) to null.Setting the variable to null makes the Thread object it previously contained available for garbage collection so that the applet can be removed from memory after a certain amount of time.If the reader comes back to this page and this applet, the start method creates a new thread and starts up the applet once again.And that's it! Four basic modifications, and now you have a well-behaved applet that runs in its own thread.The Problem with ParallelismIf threading is so wonderful, why doesn't every system have it? Many modern operating systems have the basic primitives needed to create and run threads, but they are missing a key ingredient.The rest of their environment is not thread-safe.Imagine that you are in a thread, one of many, and each of you is sharing some important data managed by the system.If you were managing that data, you could take steps to protect it (as you'll see later in this chapter), but the system is managing it.Now visualize a piece of code in the system that reads some crucial value, thinks about it for a while, and then adds 1 to the value:if (crucialValue > 0) {.// think about what to do crucialValue += 1;}Remember that any number of threads may be calling upon this part of the system at once.The disaster occurs when two threads have both executed the if test before either has incremented the crucialValue.In that case, the value is clobbered by them both with the same crucialValue + 1, and one of the increments has been lost.This may not seem so bad to you, but imagine instead that the crucial value affects the state of the screen as it is being displayed.Now, unfortunate ordering of the threads can cause the screen to be updated incorrectly.In the same way, mouse or keyboard events can be lost, databases can be inaccurately updated, and so forth.This disaster is inescapable if any significant part of the system has not been written with threads in mind.Therein lies the barrier to a mainstream threaded environment—the large effort required to rewrite existing libraries for thread safety.Luckily, Java was written from scratch with this is mind, and every Java class in its library is thread-safe.Thus, you now have to worry only about your own synchronization and thread-ordering problems, because you can assume that the Java system will do the right thing.NOTESome readers may wonder what the fundamental problem really is.Can't you just make the [ Pobierz całość w formacie PDF ]

Linki