Core Java:
Computer users take it for granted that their systems can do more than one thing at a time. They assume that they can continue to work in a word processor, while other applications download files, manage the print queue, and stream audio. Even a single application is often expected to do more than one thing at a time. For example, that streaming audio application must simultaneously read the digital audio off the network, decompress it, manage playback, and update its display. Even the word processor should always be ready to respond to keyboard and mouse events, no matter how busy it is reformatting text or updating the display. Software that can do such things is known as concurrent software.The Java platform is designed from the ground up to support concurrent programming with basic concurrency support in the Java programming language and the Java class libraries. Since version 5.0, the Java platform has also included high-level concurrency APIs.
Processes and Threads In concurrent programming, there are two basic units of execution: processes and threads. In the Java programming language, concurrent programming is mostly concerned with threads. However, processes are also important.
A computer system normally has many active processes and threads. This is true even in systems that only have a single execution core, and thus only have one thread actually executing at any given moment. Processing time for a single core is shared among processes and threads through an OS feature called time slicing.
It's becoming more and more common for computer systems to have multiple processors or processors with multiple execution cores. This greatly enhances a system's capacity for concurrent execution of processes and threads - but concurrency is possible even on simple systems, without multiple processors or execution cores.
A process has a self-contained execution environment. A process generally has a complete, private set of basic run-time resources; in particular, each process has its own memory space. Processes are often seen as synonymous with programs or applications. However, what the user sees as a single application may in fact be a set of cooperating processes. To facilitate communication between processes, most operating systems support Inter Process Communication (IPC) resources, such as pipes and sockets. IPC is used not just for communication between processes on the same system, but processes on different systems.
Most implementations of the Java virtual machine run as a single process. A Java application can create additional processes using a ProcessBuilder object. Multiprocess applications are beyond the scope of this lesson.
Threads Threads are sometimes called lightweight processes. Both processes and threads provide an execution environment, but creating a new thread requires fewer resources than creating a new process.
Threads exist within a process - every process has at least one thread. Threads share the process's resources, including memory and open files. This makes for efficient, but potentially problematic, communication.
Multithreaded execution is an essential feature of the Java platform. Every application has at least one thread - or several, if you count "system" threads that do things like memory management and signal handling. But from the application programmer's point of view, you start with just one thread, called the main thread.
Thread Objects
Each thread is associated with an instance of the class Thread. There are two basic strategies for using Thread objects to create a concurrent application.
* To directly control thread creation and management, simply instantiate Thread each time the application needs to initiate an asynchronous task.
* To abstract thread management from the rest of your application, pass the application's tasks to an executor.
Defining and Starting a Thread
An application that creates an instance of Thread must provide the code that will run in that thread. There are two ways to do this:
* Provide a Runnable object: The Runnable interface defines a single method, run, meant to contain the code executed in the thread. The Runnable object is passed to the Thread constructor, as in the HelloRunnable example:
public class HelloRunnable implements Runnable {
public void run() {
System.out.println("Hello from a thread!");
}
public static void main(String args[]) {
(new Thread(new HelloRunnable())).start();
}
}
*. Subclass Thread: The Thread class itself implements Runnable, though its run method does nothing. An application can subclass Thread, providing its own implementation of run, as in the HelloThread example:
public class HelloThread extends Thread {
public void run() {
System.out.println("Hello from a thread!");
}
public static void main(String args[]) {
(new HelloThread()).start();
}
}
Notice that both examples invoke Thread.start in order to start the new thread.Which of these idioms should you use? The first idiom, which employs a Runnable object, is more general, because the Runnable object can subclass a class other than Thread. The second idiom is easier to use in simple applications, but is limited by the fact that your task class must be a descendant of Thread. This lesson focuses on the first approach, which separates the Runnable task from the Thread object that executes the task. Not only is this approach more flexible, but it is applicable to the high-level thread management APIs covered later. The Thread class defines a number of methods useful for thread management. These include static methods, which provide information about, or affect the status of, the thread invoking the method. The other methods are invoked from other threads involved in managing the thread and Thread object.
Different states of a thread are:
When you are programming with threads, understanding the life cycle of thread is very valuable. While a thread is alive, it is in one of several states. By invoking start() method, it doesn't mean that the thread has access to CPU and start executing straight away. Several factors determine how it will proceed.
New state - After the creations of Thread instance the thread is in this state but before the start() method invocation. At this point, the thread is considered not alive. Runnable (Ready-to-run) - A thread starts its life from Runnable state. A thread first enters runnable state after the invoking of start() method but a thread can return to this state after either running, waiting, sleeping or coming back from blocked state also. On this state a thread is waiting for a turn on the processor.
Running - A thread is in running state that means the thread is currently executing. There are several ways to enter in Runnable state but there is only one way to enter in Running state: the scheduler select a thread from runnable pool.
Dead - A thread can be considered dead when its run() method completes. If any thread comes on this state that means it cannot ever run again.
Blocked - A thread can enter in this state because of waiting the resources that are hold by another thread.
Different states implementing Multiple-Threads are:
.....................diagtram..................
As we have seen different states that may be occur with the single thread, a running thread can enter to any non-runnable state, depending on the circumstances. A thread cannot enter directly to the running state from non-runnable state, firstly it goes to runnable state. Now let's understand the some non-runnable states which may be occur handling the multithreads. Sleeping - On this state, the thread is still alive but it is not runnable, it might be return to runnable state later, if a particular event occurs. On this state a thread sleeps for a specified amount of time. You can use the method sleep( ) to stop the running state of a thread.
static void sleep(long millisecond) throws InterruptedException Waiting for Notification - A thread waits for notification from another thread. The thread sends back to runnable state after sending notification from another thread. final void wait(long timeout) throws InterruptedException final void wait(long timeout, int nanos) throws InterruptedException final void wait() throws InterruptedException
Blocked on I/O - The thread waits for completion of blocking operation. A thread can enter on this state because of waiting I/O resource. In that case the thread sends back to runnable state after availability of resources.
Blocked for joint completion - The thread can come on this state because of waiting the completion of another thread.
Blocked for lock acquisition - The thread can come on this state because of waiting to acquire the lock of an object.
Methods that can be applied on a Thread:
Some Important Methods defined in java.lang.Thread are shown in the table:
Method - - Return Type - Description
currentThread( )-- -- Thread -- Returns an object reference to the thread in which it is invoked.
getName( ) -- String -- Retrieve the name of the thread object or instance.
start( ) -- void -- Start the thread by calling its run method.
run( ) -- void - This method is the entry point to execute thread, like the main method for applications.
sleep( ) -- void -- Suspends a thread for a specified amount of time (in milliseconds).
isAlive( ) -- boolean -- This method is used to determine the thread is running or not.
activeCount( ) -- Int -- This method returns the number of active threads in a particular thread group and all its subgroups.
interrupt( ) -- void -- This method interrupts the threads on which it is invoked.
yield( ) -- Void -- By invoking this method the current thread pause its execution temporarily and allow other threads to execute.
join( ) -- Void -- Join() and join(long millisec) throws InterruptedException. These are not returned until either the thread has completed or it is timed out respectively.
Synchronization
Threads communicate primarily by sharing access to fields and the object references these fields refer to. This form of communication is extremely efficient, but makes two kinds of errors possible: thread interference and memory consistency errors. The tool needed to prevent these errors is synchronization.
* Thread Interference describes how errors are introduced when multiple threads access shared data. * Memory Consistency Errors describes errors that result from inconsistent views of shared memory. * Synchronized Methods describes a simple idiom that can effectively prevent thread interference and memory consistency errors. * Implicit Locks and Synchronization describes a more general synchronization idiom, and describes how synchronization is based on implicit locks. * Atomic Access talks about the general idea of operations that can't be interfered with by other threads.
A Synchronized Class Example The class, SynchronizedRGB, defines objects that represent colors. Each object represents the color as three integers that stand for primary color values and a string that gives the name of the color.
public class SynchronizedRGB {
// Values must be between 0 and 255.
private int red;
private int green;
private int blue;
private String name;
private void check(int red,
int green,
int blue) {
if (red < 0 || red > 255
|| green < 0 || green > 255
|| blue < 0 || blue > 255) {
throw new IllegalArgumentException();
}
}
public SynchronizedRGB(int red,
int green,
int blue,
String name) {
check(red, green, blue);
this.red = red;
this.green = green;
this.blue = blue;
this.name = name;
}
public void set(int red,
int green,
int blue,
String name) {
check(red, green, blue);
synchronized (this) {
this.red = red;
this.green = green;
this.blue = blue;
this.name = name;
}
}
public synchronized int getRGB() {
return ((red << 16) | (green << 8) | blue);
}
public synchronized String getName() {
return name;
}
public synchronized void invert() {
red = 255 - red;
green = 255 - green;
blue = 255 - blue;
name = "Inverse of " + name;
}
}
SynchronizedRGB must be used carefully to avoid being seen in an inconsistent state. Suppose, for example, a thread executes the following code:
SynchronizedRGB color =
new SynchronizedRGB(0, 0, 0, "Pitch Black");
...
int myColorInt = color.getRGB(); //Statement 1
String myColorName = color.getName(); //Statement 2
If another thread invokes color.set after Statement 1 but before Statement 2, the value of myColorInt won't match the value of myColorName. To avoid this outcome, the two statements must be bound together:
synchronized (color) {
int myColorInt = color.getRGB();
String myColorName = color.getName();
}
This kind of inconsistency is only possible for mutable objects - it will not be an issue for the immutable version of SynchronizedRGB.Deadlock Deadlock describes a situation where two or more threads are blocked forever, waiting for each other. Here's an example. Below where the deadlock condition is occurred:
In this diagram two threads having the Printing & I/O operations respectively at a time. But Thread1 need printer that is hold up by the Thread2, likewise Thread2 need the keyboard that is hold up by the Thread1. In this situation the CPU becomes ideal and the deadlock condition occurs because no thread is executed until the held up resources are free Another Example to show DeadLock condition:
In this example, there are two thread objects myThread and yourThread. When myThread starts running it holds lock on str1 object. If now yourThread strarts it gets lock on str2. Now when first thread continues and wants lock on str2 then it is not available because second thread already holds lock on str2. Now both threads will wait for each other. myThread waits for str2 to be released by yourThread and yourThread is waiting for str1 to be released by myThread. This program now goes to deadlock condition. Now if you want to break the program then you need to press CTRL+C from keyboard.
DeadLockDemo.java
import java.util.*;
public class DeadLockDemo extends Thread
{
public static String str1 = "str1";
public static String str2 = "str2";
public static void main(String[] a)
{
Thread myThread = new MyThread();
Thread yourThread = new YourThread();
myThread.start();
yourThread.start();
}
private static class MyThread extends Thread
{
public void run()
{
synchronized (str1)
{
System.out.println("MyThread Holds lock on object str1");
try
{
Thread.sleep(10);
}
catch (InterruptedException e)
{
}
System.out.println("MyThread waiting for lock on object str2");
synchronized (str2)
{
System.out.println("MyThread Holds lock on objects str1, str2");
}
}
}
}
private static class YourThread extends Thread
{
public void run()
{
synchronized (str2)
{
System.out.println("YourThread Holds lock on object str2");
try
{
Thread.sleep(10);
}
catch (InterruptedException e)
{
}
System.out.println("YourThread waiting for lock on object str1");
synchronized (str1)
{
System.out.println("YourThread Holds lock on objects str1, str2");
}
}
}
}
}
Output: C:\Users\Madhu\Desktop\Madhu>java -classpath . DeadLockDemo
MyThread Holds lock on object str1
YourThread Holds lock on object str2
YourThread waiting for lock on object str1
MyThread waiting for lock on object str2
Screen would stuck here until we do CTRL + C Each time an object is created in Java it goes into the area of memory known as heap. The primitive variables like int and double are allocated in the stack if they are local method variables and allocated in the heap if they are member variables (i.e. fields of a class). In Java method's local variables are pushed into stack when a method is invoked and stack pointer is decremented when a method call is completed. In a multi-threaded application each thread will have its own stack but will share the same heap. This is why care should be taken in your code to avoid any concurrent access issues in the heap space. The stack is thread safe (each thread will have its own stack) but the heap is not thread safe unless guarded with synchronization through your code.
A method in stack is reentrant allowing multiple concurrent invocations that do not interfere with each other. A function is recursive if it calls itself. Given enough stack space, recursive method calls are perfectly valid in Java though it is tough to debug. Recursive functions are useful in removing iterations from many sorts of algorithms. All recursive functions are re-entrant but not all re-entrant functions are recursive. Idempotent methods are methods, which are written in such a way that repeated calls to the same method with the same arguments yield same results. For example clustered EJBs, which are written with idempotent methods, can automatically recover from a server failure as long as it can reach another server.
Type casting means treating a variable of one type as though it is another type.
When up casting primitives as shown below from left to right, automatic conversion occurs. But if you go from right to left, down casting or explicit casting is required. Casting in Java is safer than in C or other languages that allow arbitrary casting. Java only lets casts occur when they make sense, such as a cast between a float and an int. However you can't cast between an int and a String (is an object in Java).
byte -> short -> int -> long -> float -> double
int i = 5;
long j = i; //Right. Up casting or implicit casting
byte b1 = i; //Wrong. Compile time error "Type Mismatch".
byte b2 = (byte) i ; //Right. Down casting or explicit casting is required.
When it comes to object references you can always cast from a subclass to a superclass because a subclass object is also a superclass object. You can cast an object implicitly to a super class type (ie upcasting). If this were not the case polymorphism wouldn't be possible.
You can cast down the hierarchy as well but you must explicitly write the cast and the object must be a legitimate instance of the class you are casting to. The ClassCastException is thrown to indicate that code has attempted to cast an object to a subclass of which it is not an instance. We can deal with the problem of incorrect casting in two ways:
# Use the exception handling mechanism to catch ClassCastException.
try{
Object o = new Integer(1);
System.out.println((String) o);
}
catch(ClassCastException cce) {
logger.log("Invalid casting, String is expected…Not an Integer");
System.out.println(((Integer) o).toString());
}
# Use the instanceof statement to guard against incorrect casting.
If(v2 instanceof Car) {
Car c2 = (Car) v2;
}
Yes. Refer diagram below.
In this code below, which implementation method will be called for these two call statement w.add(impl1); w.add(impl2);
interface iA
class iAimplOne implements iA
class iAimplTwo implements iA
class Work{
public void add(iA obj)
{
System.out.println("Common");
}
public void add(iAimplOne obj)
{
System.out.println("One");
}
public void add(iAimplTwo obj)
{
System.out.println("Two");
}
}
class Main{
public static void main(String args[]){
Work w=new Work();
iAimplOne impl1 = new iAimplOne();
iAimplTwo impl2 = new iAimplTwo();
w.add(impl1);
w.add(impl2);
}
}
C:\Users\Madhu\Desktop\Madhu\Java\InterfaceTest>java -cp . MainOne
Two
Object method()
String method()
Is this overloading? will it compile?
Can this be overriding, how?
Compilation Fails. This is not overloading because method signature is same. As per the rules of overloading, method signature should not be same (The signature of a method is the combination of the method's name along with the number and types of the parameters (and their order).)
class ObjectString
{
Object method(){}
String method(){}
}
C:\Users\Madhu\Desktop\Madhu\Java>javac -cp . ObjectString.javaObjectString.java:4: method() is already defined in ObjectString
String method(){}
^
1 error
class ObjectString
{
String method(){}
Object method(){}
}
C:\Users\Madhu\Desktop\Madhu\Java>javac -cp . ObjectString.javaObjectString.java:5: method() is already defined in ObjectString
Object method(){}
^
1 error
This is not overriding as well because method return type must be same as super class method.
The following methods have been overriden
method(Object)
method(String)
So, if we call method(null) which method will execute.
Solution:
class B
{
void method(String s)
{
System.out.println("B");
}
}
class A extends B
{
void method(Object o)
{
System.out.println("A");
}
}
class ObjectString
{
public static void main(String args[])
{
A a=new A();
a.method(new Object());
a.method(null);
}
}
C:\Users\Madhu\Desktop\Madhu\Java>java -cp . ObjectStringA
B
If a method in super class throws SQLException, and the method has been overriden, and in the overridden method i am getting 2 exceptions, SQLException and IOException. what should be done in that case.
Solution:
import java.io.*;
import java.sql.*;
class Base{
public static void amethod() throws SQLException{}
}
public class ExcepDemoAlt extends Base{
public static void amethod() throws SQLException{
try{ throw new IOException();}
catch(IOException e){}
}
}
Servlets & JSP:
If any class qualifies as servlet that class must be subclass of Servlet interface directly or indirectly. The Servlet interface has three methods which play the key role in servlet life cycle. The three method of servlet life cycle are:
Init()
Service()
Destroy()
The life cycle of a servlet starts only and only when a call is given to that servlet.
Whenever a request is going to server for a servlet, the server looks for a particular servlet instance. If the instance is not found, it will be created and the init() method of that servlet will be called. Calling of the init() method is one time process in life cycle of the servlet. And a thread will be allocated to process the same request.
So whenever we are giving the first request to the server for servlet, it takes the URL pattern and identify by the URL that which servlet has to call. And then creates the object of that and calls the init() method.
If you make the second request for same servlet than server will not create a new object for that servlet and also do not call the init() method also. A new thread will be created and will be allocated to handle the request.
So if ten different requests are coming at the same time for same servlet then server will allocate thread to each request using one object.
After allocating thread, the service () method of the servlet will be called where the main business logic will be executed and give response back to the request.
So the service method will be called for each request.
Finally whenever the servlet object become amended for much time or server is going down the destroy () method of servlet will be called.
A diagram of the servlet life cycle is given below.
The doGet() and doPost() methods are specefically meant for a servlet which extends HttpServlet which in itself extends GenericServlet class.
So whenever a request comes up firstly it goes to service() method which redirects it to doGet() or doPost() method depending on the request i.e if it is get type request it will go to doGet() and if its kinda POST request it will go to doPost().
Any sub class of javax.servet.Servlet is considered as servlet, this Servlet Interface contains 3 life cycle methods (ofcourse 2 more methods r there) namely init(),service(),destroy().
API providing built in abstract class javax.servlet.GenericServlet with one abstract method service(), it provides basic implementation of all other methods. GenericServlet is protocol independent, you can use these for your custom protocol also, now comming to javax.servlet.http.HttpServlet. (which extends GenericServlet) this is for only http protocol, in this class service() method is implemented, internally service method will call doGet()/doPost()/doTrace()/doDelete()/doPut() etc. dependent on the http method.
Coming to difference between doGet() and doPost... we should say it as diff b/w http get and post methods. the major difference is about security..
In GET, the param values (in a web form) will be appended at the address bar in browser, hence not secure, limited data can be sent through get, and this is the default method (for html form)
Whereas POST is secure as it will not show the param values on address bar of browser. We can send huge data through post method
Initially every request reaches to service() method and depends on http method, service method calls doGet()/doPost() etc...
----------------
A Generic servlet contains the following five methods:
init()
public void init(ServletConfig config) throws ServletException
The init() method is called only once by the servlet container throughout the life of a servlet. By this init() method the servlet get to know that it has been placed into service.
The servlet cannot be put into the service if
* The init() method does not return within a fix time set by the web server.
* It throws a ServletException
Parameters - The init() method takes a ServletConfig object that contains the initialization parameters and servlet's configuration and throws a ServletException if an exception has occurred.
service() BR>
public void service(ServletRequest req, ServletResponse res) throws ServletException, IOException
Once the servlet starts getting the requests, the service() method is called by the servlet container to respond. The servlet services the client's request with the help of two objects. These two objects javax.servlet.ServletRequest and javax.servlet.ServletResponse are passed by the servlet container.
The status code of the response always should be set for a servlet that throws or sends an error
Parameters - The service() method takes the ServletRequest object that contains the client's request and the object ServletResponse contains the servlet's response. The service() method throws ServletException and IOExceptions exception
getServletConfig()
public ServletConfig getServletConfig()
This method contains parameters for initialization and startup of the servlet and returns a ServletConfig object. This object is then passed to the init method. When this interface is implemented, it stores the ServletConfig object in order to return it. It is done by the generic class which implements this inetrface.
Returns - the ServletConfig object
getServletInfo()
public String getServletInfo()
The information about the servlet is returned by this method like version, author etc. This method returns a string which should be in the form of plain text and not any kind of markup.
Returns - a string that contains the information about the servlet
destroy()
public void destroy()
This method is called when we need to close the servlet. That is before removing a servlet instance from service, the servlet container calls the destroy() method. Once the servlet container calls the destroy() method, no service methods will be then called . That is after the exit of all the threads running in the servlet, the destroy() method is called. Hence, the servlet gets a chance to clean up all the resources like memory, threads etc which are being held. Following diagram shows the different life cycle stages of jsp. Broadly, these stages can be classified into three.
* Instantiation
* Request Processing
* Destruction
Instantiation: When a web container receives a jsp request (may be first or subsequent), it checks for the jsp's servlet instance. If no servlet instance is available or if it is older than the jsp, then, the web container creates the servlet instance using following stages.
* Translation
* Compilation
* Loading
* Instantiation
* Initialization
Translation:
Web container translates (converts) the jsp code into a servlet code. This means that jsp is actually a servlet. After this stage, there is no jsp, everything is a servlet. This task will create a complete jsp page, by considering all included components. Here on, the static content and dynamic contents are treated differently. The resultant is a java class instead of an html page (which we wrote).
The below is how the structure of a jsp compiled into a java class will be.
package org.apache.jsp.WEB_002dINF.jsp;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
public final class firstJsp_jsp extends org.apache.jasper.runtime.HttpJspBase
implements org.apache.jasper.runtime.JspSourceDependent {
private static final JspFactory _jspxFactory = JspFactory.getDefaultFactory();
............
............
public Object getDependants() {
return _jspx_dependants;
}
public void _jspInit() {
............
............
}
public void _jspDestroy() {
............
............
}
public void _jspService(HttpServletRequest request,
HttpServletResponse response)
throws java.io.IOException, ServletException {
............
............
}
............
............
}
Compilation:
The generated servlet is compiled to validate the syntax. As it is a java class, the compilation is done using javac command. This will generate the byte code to be run on JVM. Loading:
The compiled byte code is loaded by the class loader used by web container. This is a standard process of using any java class. Instantiation:
In this step, instance of the servlet class is created so that it can serve the request.
Initialization:
Initialization is done by calling the jspInit() method. This is one time activity at the start of the initialization process. Initialization will make the ServletContext and ServletConfig objects available. One can access many attributes related to the web container and the servlet itself. After initialization the servlet is ready to process requests. Request Processing:
Entire initialization process is done to make the servlet available in order to process the incoming request. jspService() is the method that actually processes the request. It prints the response in html (any other) format, using 'out' object.
Destroy:
Whenever the server is shutting down or when the server needs memory, the server removes the instance of the servlet. The destroy method jspDestroy() can be called by the server after initialization and before or after request processing. Once destroyed the jsp needs to be initialized again.
Just to summarize, web container handles incoming requests to a jsp by converting it into a servlet and then by using this servlet to generate the response. Also when the server shuts down, the container needs to clear the instances.
Controlling Life Cycle: In above discussion, we understood that the jsp initialization phase happens when the first request hits the web container. This might take more time to present the response to the first user of jsp. It should be possible to keep initialized servlets ready to receive first request and immediately return response. This can be achieved by using the attributes provided by web and application server. The attribute can be "load-on-startup", "pre compile" etc.
No comments:
Post a Comment