That's interesting to me.

[shumtar-blog]

Direct writing data to ram memory in java

During investigation class AbstractQueuedSynchronizer and AtomicInteger i’ve seen sun.misc.Unsafe object which contains method compareAndSwapInt.

The class Unsafe contains a collection of methods for performing low-level, unsafe operations.  Although the class and all methods are public, use of this class is  limited because only trusted code can obtain instances of it.

It contains many interesting methods (see more on http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/src/share/classes/sun/misc/Unsafe.java) like next:

    public native short   getShort(long address);

    public native void    putShort(long address, short x);

    public native char    getChar(long address);

    public native void    putChar(long address, char x);

    public native int     getInt(long address);

    public native void    putInt(long address, int x);

    public native long    getLong(long address);

    public native void    putLong(long address, long x);

    public native float   getFloat(long address);

    public native void    putFloat(long address, float x);

    public native double  getDouble(long address);

    public native void    putDouble(long address, double x);

  I tried to get object unsafe in normal way:

Unsafe unsafe=Unsafe.getUnsafe();

and will thrown

        Exception in thread "main" java.lang.SecurityException: Unsafe

        at sun.misc.Unsafe.getUnsafe(Unsafe.java:90)

  To eliminate this exception,the alternate way is next:

Unsafe unsafe=Unsafe.getUnsafe(); try {     f = Unsafe.class.getDeclaredField("theUnsafe");     f.setAccessible(true);     unsafe = (Unsafe) f.get(null); } catch (IllegalAccessException  | NoSuchFieldException e) {     e.printStackTrace(); }

Full sample is listed bellow:

package com.app.unsafesample; import sun.misc.Unsafe; import java.lang.reflect.Field; public class App { public static final int SIZE_IN_BYTES = 4; public static void main(String[] args) { Field f = null; Unsafe unsafe=null; try { f = Unsafe.class.getDeclaredField("theUnsafe"); f.setAccessible(true); unsafe = (Unsafe) f.get(null); } catch (IllegalAccessException | NoSuchFieldException e) { e.printStackTrace(); } int sampleValue=245; long allocatedMemory = unsafe.allocateMemory(SIZE_IN_BYTES); unsafe.putInt(allocatedMemory,sampleValue); int valueFromMemory=unsafe.getInt(allocatedMemory); System.out.println(valueFromMemory); } }

Outputs: 245

For primitive values is required to remember memory size: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html For interested in to dug into Unsafe class: source code: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/src/share/classes/sun/misc/Unsafe.java and fantastic post: http://java.dzone.com/articles/understanding-sunmiscunsafe

[shumtar-blog]

Atomic variables

Typically, when you need to share an updateable variable among threads, synchronization is used. Synchronization among multiple threads used to be achieved using the synchronized keyword and it was based on an object’s monitor. If a thread is not able to acquire an object’s monitor, that thread is suspended and it has to be resumed later. This way of synchronization (suspending and resuming) uses a great deal of system resources. The problem is not in the locking and unlocking mechanism of the monitor lock; rather it is in suspending and resuming the threads.

An atomic variable uses a lock-free synchronization of a single variable. Note that if your program needs to synchronize on more than one shared variable, you still need to use the old synchronization methods. By lock-free synchronization, I mean that multiple threads can access a shared variable safely using no object monitor lock. JDK takes advantage of a hardware instruction called “compare-and-swap" (CAS) to implement the lock-free synchronization for one variable.

CAS is based on three operands: a memory location M, an expected old value O, and a new value N. If the memory location M contains a value O, CAS updates it atomically to N; otherwise, it does not do anything. CAS always returns the current value at the location M that existed before the CAS operation started. The pseudo code for CAS is as follows:

CAS(M, O, N) { currentValueAtM = get the value at Location M; if (currentValueAtM == O) { set value at M to N; } return currentValueAtM; }

The CAS instruction is lock free. It is directly supported in most modern computers’ hardware. However, CAS is not always guaranteed to succeed in a multi-threaded environment. CAS takes an optimistic approach by assuming that there are no other threads updating the value at location M; if the location M contains value O, update it to N; if the value at location M is not O, do not do anything. Therefore, if multiple threads attempt to update the value at location M to different values simultaneously, only one thread will succeed and others will fail.

Atomic variable classes are named like AtomicXxx, and can be used to execute multiple instructions on a single variable atomically without using any lock. Here, Xxx is replaced with different words to indicate different classes that are used for different purposes; for example, the AtomicInteger class is used to represent an int variable, which is supposed to be manipulated atomically. Twelve classes in the Java class library support read-modify-write operations on a single variable atomically.*1

Instances of classes AtomicBoolean, AtomicInteger, AtomicLong, and AtomicReference each provide access and updates to a single variable of the corresponding type. Each class also provides appropriate utility methods for that type. For example, classes AtomicLong and AtomicInteger provide atomic increment methods. One application is to generate sequence numbers, as in:

class Sequencer { private final AtomicLong sequenceNumber = new AtomicLong(0); public long next() { return sequenceNumber.getAndIncrement(); } }

It is straightforward to define new utility functions that, like getAndIncrement, apply a function to a value atomically. For example, given some transformation

long transform(long input)

write your utility method as follows:

long getAndTransform(AtomicLong var) { while (true) { long current = var.get(); long next = transform(current); if (var.compareAndSet(current, next)) return current; // return next; for transformAndGet } }

In addition to classes representing single values, this package contains Updater classes that can be used to obtain compareAndSet operations on any selected volatile field of any selected class. AtomicReferenceFieldUpdater, AtomicIntegerFieldUpdater, and AtomicLongFieldUpdater are reflection-based utilities that provide access to the associated field types. These are mainly of use in atomic data structures in which several volatile fields of the same node (for example, the links of a tree node) are independently subject to atomic updates. These classes enable greater flexibility in how and when to use atomic updates, at the expense of more awkward reflection-based setup, less convenient usage, and weaker guarantees.*2

*1 Beginning Java Language Features By Kishori Sharan

*2 Android API java.util.concurrent.atomic

[shumtar-blog]

Factory pattern

An important facet of system design is the manner in which objects are created. Although far more time is often spent considering the object model and instance interaction, if this simple design aspect is ignored it will adversely impact the entire system. Thus, it is not only important what an object does or what it models, but also in what manner it was created.

One of the most widely used creational patterns is the Factory. This pattern is aptly named, as it calls for the use of a specialized object solely to create other objects, much like a real-world factory.

The idea behind the Factory Method pattern is that it allows for the case where a client doesn't know what concrete classes it will be required to create at runtime, but just wants to get a class that will do the job. You'll see factories used in logging frameworks, and in a lot of scenarios where the client doesn't need to know about the concrete implementations. It's a good approach to encapsulation.

As with other design patterns, there are countless variations of the Factory pattern, although most variants typically used the same set of primary actors, a client, a factory, and a product. The client is an object that requires an instance of another object (the product) for some purpose. Rather than creating the product instance directly, the client delegates this responsibility to the factory. Once invoked, the factory creates a new instance of the product, passing it back to the client. Put simply, the client uses the factory to create an instance of the product. Figure 1 shows this logical relationship between these elements of the pattern.

Figure1.

The factory completely abstracts the creation and initialization of the product from the client. This indirection enables the client to focus on its discrete role in the application without concerning itself with the details of how the product is created. Thus, as the product implementation changes over time, the client remains unchanged.

Consider an application that models the assembly of a variety of personal computers. The application contains a ComputerAssembler class that is responsible for the assembly of the computer, a Computer class that models the computer being built, and a ComputerFactory class that creates instances of the Computer class. In using the Factory pattern, the ComputerAssembler class delegates responsibility for creation of Computer instances to the ComputerFactory. This ensures that if the instantiation and/or initialization process changes (e.g. new constructor, use of an activator, custom pooling, etc.), the ComputerAssembler does not need to change at all. This is the benefit of abstracting the creation of an object from its use.

In addition, suppose that the business requirements changed and a new type of computer needs to be assembled. Rather than modifying the ComputerAssembler class directly, the ComputerFactory class can be modified to create instances of a new computer class (assuming that this new class has the same interface as Computer). Furthermore, it is also possible to address this requirement by creating a new factory class (that has the same interface as ComputerFactory) that creates instances of the new computer class (again, with the same interface as Computer). As before, nothing in the ComputerAssembler class needs to change, all the logic just continues to work as it had previously. This is the benefit of abstracting the types of the product and factory into invariant interfaces.

Physical Model

Most implementations of the Factory pattern use two abstract classes, Factory and Product, to provide the invariant interfaces discussed in the logical model. Although we could utilize pure interfaces for this purpose, the use of abstract classes enables us to place common instance behavior in the abstract class.

As shown in Figure 2, the Client uses an instance of a concrete subclass of Factory (ConcreteFactory) to create an instance of a concrete Product subclass (ConcreteProduct). Since all variables, parameters, and method return values are typed to the Factory and Product abstract classes, the Client is unaware of the introduction of these subclasses. This enables the introduction of new Factory and Product subclasses as requirements warrant; nothing needs to change within the Client. It is worth noting that this pattern does not dictate the use of the specific names (i.e. client, factory, product) used within the physical model, rather the use of these names is only to provide clarity in terms of the role each type plays in the pattern.

Figure2

Using our previously defined computer assembly application, let's examine a simple implementation of the Factory pattern

package com.example.factorypettern.computer; public abstract class Computer { abstract public int getMhz(); } } package com.example.factorypettern.factory; import com.example.factorypettern.computer.Computer; public abstract class ComputerFactory { public abstract Computer getComputer(); }

The above code fragment outlines the Computer and ComputerFactory abstract classes. These types represent the invariant factory and product interfaces required by the physical model. The ConcreteComputer and ConcreteComputerFactory classes found below extend these abstract classes. The ConcreteComputer class overrides the Mhz property of the Computer class, returning the value of 500. The ConceteComputerFactory overrides the GetComputer method of the ComputerFactory class returning a new instance of ConcreteComputer.

package com.example.factorypettern.computer; public class ConcreteComputer extends Computer { private int mhz = 50; @Override public int getMhz() { return mhz; } } package com.example.factorypettern.factory; import com.example.factorypettern.computer.Computer; import com.example.factorypettern.computer.ConcreteComputer; public class ConcreteComputerFactory extends ComputerFactory { @Override public Computer getComputer() { return new ConcreteComputer(); } }

The ComputerAssembler class, found below, provides one method, AssembleComputer. This method accepts one parameter that must be an object whose class extends the ComputerFactory abstractclass. This method then uses this factory instance to create an instance of some class that extends the Computer abstract class. Although the ComputerAssembler is blissfully unaware of the actual subclass of Computer that it is using, it is still able to print its type (via type introspection) and determine the MHz of the computer. The Appclass, also found below, is the entry point for the sample. It creates an instance of the ComputerAssembler and invokes the AssembleComputer method passing an instance of a class that extends ComputerFactory.

package com.example.factorypettern.computerassemblers; import com.example.factorypettern.computer.Computer; import com.example.factorypettern.factory.ComputerFactory; public class ComputerAssembler { public void assembleComputer(ComputerFactory computerFactory){ Computer computer=computerFactory.getComputer(); String computerName = computer.getClass().getSimpleName(); System.out.printf("assembled a %s running at %s MHz",computerName,computer.getMhz()); } } package com.example.factorypettern; import com.example.factorypettern.computerassemblers.ComputerAssembler; import com.example.factorypettern.factory.ComputerFactory; import com.example.factorypettern.factory.ConcreteComputerFactory; public class App { public static void main(String[] args) { final ComputerFactory computerFactory=new ConcreteComputerFactory(); final ComputerAssembler computerAssembler=new ComputerAssembler(); computerAssembler.assembleComputer(computerFactory); } }

After program running result is next: assembled a ConcreteComputer running at 50 MHz Process finished with exit code 0

In order to illustrate the benefits of factory and product type abstraction, suppose that the application was required to assemble two different computer types, rather than only one. For the purposes of this example, we create an additional factory, BrandXFactory, and a related product class, BrandXComputer, as shown below.

package com.example.factorypettern.computer; public class BrandXComputer extends Computer { private int mhz = 1500; @Override public int getMhz() { return mhz; } } package com.example.factorypettern.factory; import com.example.factorypettern.computer.BrandXComputer; import com.example.factorypettern.computer.Computer; public class BrandXFactory extends ComputerFactory { @Override public Computer getComputer() { return new BrandXComputer(); } }

With the new factory and product in place, we now need to modify the main method of the App to determine which factory to use. If the appropriate string is passed in on the command line, the BrandXFactory will be used; if there is no such command line argument, the standard ComputerFactory will be used. This modification is shown below.

package com.example.factorypettern; import com.example.factorypettern.factory.BrandXFactory; import com.example.factorypettern.factory.ComputerFactory; import com.example.factorypettern.factory.ConcreteComputerFactory; import java.util.Scanner; public class App { public static void main(String[] args) { ComputerFactory computerFactory = null; final Scanner scanner = new Scanner(System.in); final String lineFromConsole = scanner.nextLine(); if ("BrandX".equals(lineFromConsole)) { computerFactory = new BrandXFactory(); } else { computerFactory = new ConcreteComputerFactory(); } } }

Please note that there is no modification or re-implementation of the ComputerAssembler class whatsoever. This class is completely abstracted from the classes of the instances it assembles, as well as the creation and initialization of the same.*1

By now, you should be able to count the main advantages of using factory pattern. Lets note down:

The creation of an object precludes its reuse without significant duplication of code.

The creation of an object requires access to information or resources that should not be contained within the composing class.

The lifetime management of the generated objects must be centralized to ensure a consistent behavior within the application.

Final notes

Factory pattern is most suitable where there is some complex object creation steps are involved. To ensure that these steps are centralized and not exposed to composing classes, factory pattern should be used. We can see many examples of factory pattern in JDK itself e.g.

java.sql.DriverManager#getConnection()

java.net.URL#openConnection()

java.lang.Class#newInstance()

java.lang.Class#forName()*2

*1 Exploring the Factory Design Pattern *2 Factory design pattern in java

[shumtar-blog]

inter-thread actions and data races

An inter-thread action is an action performed by one thread that can be detected or directly influenced by another thread. There are several kinds of inter-thread action that a program may perform:

Read (normal, or non-volatile). Reading a variable.

Write (normal, or non-volatile). Writing a variable.

Synchronization actions, which are:

Volatile read. A volatile read of a variable.

Volatile write. A volatile write of a variable.

Lock. Locking a monitor

Unlock. Unlocking a monitor.

The (synthetic) first and last action of a thread.

Actions that start a thread or detect that a thread has terminated.

External Actions. An external action is an action that may be observable outside of an execution, and has a result based on an environment external to the execution.

Thread divergence actions. A thread divergence action is only performed by a thread that is in an infinite loop in which no memory, synchronization, or external actions are performed. If a thread performs a thread divergence action, it will be followed by an infinite number of thread divergence actions.

A set of actions is sequentially consistent if all actions occur in a total order (the execution order) that is consistent with program order, and furthermore, each read r of a variable v sees the value written by the write w to v such that:

w comes before r in the execution order, and

there is no other write w' such that w comes before w' and w' comes before r in the execution order.

Sequential consistency is a very strong guarantee that is made about visibility and ordering in an execution of a program.

Two actions can be ordered by a happens-before relationship. If one action happens-before another, then the first is visible to and ordered before the second.

The happens-before relation defines when data races take place.

It follows from the above definitions that:

An unlock on a monitor happens-before every subsequent lock on that monitor.

A write to a volatile field happens-before every subsequent read of that field.

A call to start() on a thread happens-before any actions in the started thread.

All actions in a thread happen-before any other thread successfully returns from a join() on that thread.

The default initialization of any object happens-before any other actions (other than default-writes) of a program.

When a program contains two conflicting accesses that are not ordered by a happens-before relationship, it is said to contain a data race.

Programmers do not need to reason about reorderings to determine that their code contains data races. Therefore they do not need to reason about reorderings when determining whether their code is correctly synchronized. Once the determination that the code is correctly synchronized is made, the programmer does not need to worry that reorderings will affect his or her code. A program must be correctly synchronized to avoid the kinds of counterintuitive behaviors that can be observed when code is reordered. The use of correct synchronization does not ensure that the overall behavior of a program is correct. However, its use does allow a programmer to reason about the possible behaviors of a program in a simple way.*

* The Java® Language Specification Java SE 8 Edition

[shumtar-blog]

Thread State-to-State Migration Flows

Thread.State enumeration contains the possible states of a Java thread in the underlying JVM. These states are different from the Operating System thread states. The possible values of the Thread.State are:

NEW - this state represents a new thread which is not yet started.

RUNNABLE - this state represents a thread which is executing in the underlying JVM. Here executing in JVM doesn't mean that the thread is always executing in the OS as well - it may wait for a resource from the Operating system like the processor while being in this state.

BLOCKED - this state represents a thread which has been blocked and is waiting for a moniotor to enter/re-enter a synchronized block/method. A thread gets into this state after calling Object.wait method.

WAITING - this state represnts a thread in the waiting state and this wait is over only when some other thread performs some appropriate action. A thread can get into this state either by calling - Object.wait (without timeout), Thread.join (without timeout), or LockSupport.park methods.

TIMED_WAITING - this state represents a thread which is required to wait at max for a specified time limit. A thread can get into this state by calling either of these methods: Thread.sleep, Object.wait (with timeout specified), Thread.join (with timeout specified), LockSupport.parkNanos, LockSupport.parkUntil.

TERMINATED - this state reprents a thread which has completed its execution either by returning from the run() method after completing the execution OR by throwing an exception which propagated from the run() method and hence caused the termination of the thread.

When a thread calls Object.wait method, it releases all the acquired monitors and is put into WAITING (or TIMED_WAITING if we call the timeout versions of the wait method) state. Now when the thread is notified either by notify() or by notifyAll() call on the same object then the waiting state of the thread ends and the thread starts attempting to regain all the monitors which it had acquired at the time of wait call. At one time there may be several threads trying to regain (or maybe gain for the first time) their monitors. If more than one threads attempt to acquire the monitor of a particular object then only one thread (selected by the JVM scheduler) is granted the monitor and all other threads are put into BLOCKED state.*1

*2

*1 Thread.State in Java? BLOCKED vs WAITING

*2 UML Protocol State Machine Diagram Example

[shumtar-blog]

Synchronization in java

The Java programming language provides multiple mechanisms for communicating between threads. The most basic of these methods is synchronization, which is implemented using monitors. Each object in Java is associated with a monitor, which a thread can lock or unlock. Only one thread at a time may hold a lock on a monitor. Any other threads attempting to lock that monitor are blocked until they can obtain a lock on that monitor. A thread t may lock a particular monitor multiple times; each unlock reverses the effect of one lock operation.

The synchronized statement  computes a reference to an object; it then attempts to perform a lock action on that object's monitor and does not proceed further until the lock action has successfully completed. After the lock action has been performed, the body of the synchronized statement is executed. If execution of the body is ever completed, either normally or abruptly, an unlock action is automatically performed on that same monitor.

SynchronizedStatement:

synchronized ( Expression ) Block

The type of Expression must be a reference type, or a compile-time error occurs.

If evaluation of the Expression completes abruptly for some reason, then the synchronized statement completes abruptly for the same reason.

Otherwise, if the value of the Expression is null, a NullPointerException is thrown.

Otherwise, let the non-null value of the Expression be V. The executing thread locks the monitor associated with V. Then the Block is executed, and then there is a choice:

If execution of the Block completes normally, then the monitor is unlocked and the synchronized statement completes normally.

If execution of the Block completes abruptly for any reason, then the monitor is unlocked and the synchronized statement completes abruptly for the same reason.

A single thread may acquire a lock more than once. Code is shown below.

class Sample { public static void main(String[] args) { Sample t = new Sample(); synchronized(t) { synchronized(t) { System.out.println("made it!"); } } } } }

Acquiring the lock associated with an object does not in itself prevent other threads from accessing fields of the object or invoking un-synchronized methods on the object. Other threads can also use synchronized methods or the synchronized statement in a conventional manner to achieve mutual exclusion.

* The Java® Language Specification Java SE 8 Edition

[shumtar-blog]

multithreading base concepts

A program is an algorithm expressed in a programming language.

A process is a running instance of a program with all system resources allocated by the operating system to that instance of the program. Typically, a process consists of a unique identifier, a program counter, executable code, an address space, open handles to system resources, a security context, and many other things.

A program counter, also called an instruction pointer, is a value maintained in the CPU register that keeps track of the instruction being executed by the CPU

Multitasking is the ability of an operating system to execute multiple tasks (or processes) at once.

The switching of the CPU among processes is called a context switch.

In a context switch:

the running process is stopped,

its state is saved,

the state of the process that is going to get the CPU is restored,

and the new process is run.

Typically, a process state consists of a program counter, register values used by the process, and any other pieces of information that are necessary to restore the process later. An operating system stores a process state in a data structure, which is called a process control block or a switchframe.

There are two types of multitasking:

cooperative. In cooperative multitasking, the running process decides when to release the CPU so that other processes can use it, a process may monopolize the CPU for a long time and other processes may not get a chance to run.

preemptive. In preemptive multitasking, the operating system allocates a time slice to each process. Once a process has used up its time slice, it is preempted, and the operating system assigns the CPU to another process. the operating system makes sure all processes get CPU time

Multiprocessing is the ability of a computer to use more than one processor simultaneously.

Parallel processing is the ability of a system to simultaneously execute the same task on multiple processors.

A process is also a unit of execution. All modern operating systems let you solve this problem by allowing you to create multiple units of execution within a process, where all units of execution can share address space and resources allocated to the process. Each unit of execution within a process is called a thread.

A thread maintains two things:

a program counter lets a thread keep track of the instruction that is currently executed by it.

a stack to store the values of the local variables.

A thread can also maintain its private memory, which cannot be shared with other threads, even if they are in the same process. The private memory maintained by a thread is called thread-local storage (TLS)

A program that uses multiple threads is called a multi-threaded program.*

*  Beginning Java 8 Language Features By Kishori Sharan

[shumtar-blog]

Recursion, Delegation, Redirection, Conglomeration

Recursion is a method call from an object to itself, to the same method.

class Timer {    public void countDown(int counter) {         if (counter > 0) {             this.countDown(counter--);          } else {          // Ignore this branch for now        }    } };

Delegation is a method call between two distinct objects and between dissimilar methods

class VicePresidentOfSales {        public void increaseQuarterlySales(){} } class CEO {        VicePresidentOfSales vpOfSales;        void increaseProfits() {             vpOfSales.increaseQuarterlySales();         } }

Redirection. The calling method is now asking another object to do some work, but it is asking for the same work to be done that the method itself is supposed to do. It is redirecting part of its workload to another object, but that part looks a lot like its own overall task.

interface Printer{     void print(String s); } class PrinterProxy {     Printer p;     void print(String s){         p.print(s);     } }

Together, Redirection and Delegation form the basics of how objects can be coupled.

Conglomeration is the act of bringing together disparate elements into a whole—in this case, pulling together subtasks that look little like the main task (as in Delegation), but here just one object does the work. There are no other objects to delegate or redirect work to because this is a one-object task, but it is broken down into smaller portions that are handled by different methods within the one object.

class Timer {     void goDing();     public void countDown(int counter) {         if (counter > 0) {             // Ignore this branch this time         } else {             this.goDing();         }     }; };

[shumtar-blog]

Cohesion and Coupling

Coupling is the degree to which one class knows about another class. Let us consider two classes class A and class B. If class A knows class B through its interface only i.e it interacts with class B through its API then class A and class B are said to be loosely coupled. 

If on the other hand class A apart from interacting class B by means of its interface also interacts through the non-interface stuff of class B then they are said to be tightly  coupled.

Cohesion is used to indicate the degree to which a class has a single, well-focused purpose. Coupling is all about how classes interact with each other, on the other hand cohesion focuses on how single class is designed. Higher the cohesiveness of the class, better is the OO design.

source:

Cohesion and Coupling: Two OO Design Principles