I was aware of the release of Firefox since Day 1, and kept trying to use numerous beta or trial version or even the minefield (sounds scary as the name or the real experience?) before the official release. However every time I just switched back to my lovely and sleek Chrome. Don't blame my patience, it just never worked out.
But this time, I have to say, the FF4 release is a huge success in terms of every aspect I can consider so far. The speed improvement is the topic that people keeping discussing all these two days. It's dramatically speed up everything even ten tabs are opening at the same time. The memory is another point I reckon, which used to consume nearly 700-800 MB on my poor machine, now can stably up and down around 300-400 MB. Actually this is one of the killing point for my working machine since this old PC always needs to Intellij Idea, WebLogic, SQLDeveloper and all sorts of dev tools all at once, you know how hard time I am having.
Another thing I like FF better than Chrome is it can temporarily record down the input you have put in before. Next time, you don't need to repeat those lengthy characters but just double click the text field. For me it's really helpful since I have do those boring task everyday to make sure programs never being screwed up.
Because it's only Day 2, I don't mind the add-ons are not ready for use. But please, guys, at least make some of the most common tools available ASAP. I have spent nearly half an hour this morning trying to find a good add-on for twitter. You will know the result if you do the same search now, not two days later, I reckon things may change less than 48 hours because weekend is coming :)
Anyway, now I have both Chrome and FF running at the same time finally (which also thanks for the latest upgrade of the memory), each sitting in a monitor. Before I make any final decision to stick on which browser, I will hang over, or later I may get used to the dual browser environment. Should I?
P.S. It would be nice if we can have a cross-browser bookmark application. Any recommendations?
Thursday, March 24, 2011
Sunday, March 6, 2011
Java Multithreading
I know this is one of the most basic topic that even second year university should be familiar with, however, this afternoon I have spent nearly a whole afternoon to debug some issues with Java Multi-threading, and only at that point I realized I am far far away from fully understanding the seemingly easy problem.
As I have reading through all kinds of tutorials, discussions available, I believe the best way would be to sommarize what I have found and record it as my own writing.
So here is the beginning, Java always running with a single thread if there is no request for a new thread to be spawned. However, in some circumstances, a separate thread is needed to perform some other tasks either to be parallel with the main thread or as a background job. There are two ways to achieve multi-thread in Java, as everyone should be familiar with: implements Runnable and extends Thread.
Basically, most of the time, implements Runnable should be the preference over extends Thread, unless you need to specifically override the life cycle method of the thread (which is rare). These two ways do nearly the same thing except when you subclass Thread, you are trapped in the spot that no other class can inherit as Java only allows single inheritance. While if you implements the interface, you still have the ability to extend any class you wish.
Next, let's go into the main method in the body -- run(). Actually, you have the choice to call run() and start() to execute the body. However, there is some slight differences between these two methods. run() will execute the method immediately in the current thread, and start() will spawn a new thread and the execution will be invoked undeterministicallly. As a rule of thumb, we should avoid to use run() but use start() all the time. The reason we have a multi-thread class is to run it in a separate thread. If we just call the run(), everything will run sequentially as there is no thread existed. run() should always invoked by JVM not the application.
Another point we should pay some attention is Executor which comes from JDK 5. Instead of explicitly calling new MyThread().start() to invoke the new thread, Executor can decouple the task submission from the real method perform -> executor.execute(new MyThread()).
As I have reading through all kinds of tutorials, discussions available, I believe the best way would be to sommarize what I have found and record it as my own writing.
So here is the beginning, Java always running with a single thread if there is no request for a new thread to be spawned. However, in some circumstances, a separate thread is needed to perform some other tasks either to be parallel with the main thread or as a background job. There are two ways to achieve multi-thread in Java, as everyone should be familiar with: implements Runnable and extends Thread.
Basically, most of the time, implements Runnable should be the preference over extends Thread, unless you need to specifically override the life cycle method of the thread (which is rare). These two ways do nearly the same thing except when you subclass Thread, you are trapped in the spot that no other class can inherit as Java only allows single inheritance. While if you implements the interface, you still have the ability to extend any class you wish.
Next, let's go into the main method in the body -- run(). Actually, you have the choice to call run() and start() to execute the body. However, there is some slight differences between these two methods. run() will execute the method immediately in the current thread, and start() will spawn a new thread and the execution will be invoked undeterministicallly. As a rule of thumb, we should avoid to use run() but use start() all the time. The reason we have a multi-thread class is to run it in a separate thread. If we just call the run(), everything will run sequentially as there is no thread existed. run() should always invoked by JVM not the application.
Another point we should pay some attention is Executor which comes from JDK 5. Instead of explicitly calling new MyThread().start() to invoke the new thread, Executor can decouple the task submission from the real method perform -> executor.execute(new MyThread()).
Subscribe to:
Posts (Atom)