IOC:

inversion of control (IoC) describes a design in which custom-written portions of a computer program receive the flow of control from a generic, reusable library. A software architecture with this design inverts control as compared to traditional procedural programming: in traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the reusable code that calls into the custom, or task-specific, code.

Inversion of Control (инверсия управления) — это некий абстрактный принцип, набор рекомендаций для написания слабо связанного кода. Суть которого в том, что каждый компонент системы должен быть как можно более изолированным от других, не полагаясь в своей работе на детали конкретной реализации других компонентов.
Dependency Injection (внедрение зависимостей) — это одна из реализаций этого принципа (помимо этого есть еще Factory Method, Service Locator).
IoC-контейнер — это какая-то библиотека, фреймворк, программа если хотите, которая позволит вам упростить и автоматизировать написание кода с использованием данного подхода на столько, на сколько это возможно.

DIP:

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.

SOLID

S	SRP [4]
Single responsibility principle
a class should have only a single responsibility (i.e. only one potential change in the software's specification should be able to affect the specification of the class)
O	OCP [5]
Open/closed principle
“software entities … should be open for extension, but closed for modification.”
L	LSP [6]
Liskov substitution principle
“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract.
I	ISP [7]
Interface segregation principle
“many client-specific interfaces are better than one general-purpose interface.”[8]
D	DIP [9]
Dependency inversion principle
one should “Depend upon Abstractions. Do not depend upon concretions.”[8]
Dependency injection is one method of following this principle, also  Factory Method, Service Locator


ACID

Atomicity[edit]
Main article: Atomicity (database systems)
Atomicity requires that each transaction be "all or nothing": if one part of the transaction fails, the entire transaction fails, and the database state is left unchanged. An atomic system must guarantee atomicity in each and every situation, including power failures, errors, and crashes. To the outside world, a committed transaction appears (by its effects on the database) to be indivisible ("atomic"), and an aborted transaction does not happen.

Consistency[edit]
Main article: Consistency (database systems)
The consistency property ensures that any transaction will bring the database from one valid state to another. Any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This does not guarantee correctness of the transaction in all ways the application programmer might have wanted (that is the responsibility of application-level code) but merely that any programming errors cannot result in the violation of any defined rules.

Isolation[edit]
Main article: Isolation (database systems)
The isolation property ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially, i.e., one after the other. Providing isolation is the main goal of concurrency control. Depending on concurrency control method, the effects of an incomplete transaction might not even be visible to another transaction.[citation needed]

Durability[edit]
Main article: Durability (database systems)
Durability means that once a transaction has been committed, it will remain so, even in the event of power loss, crashes, or errors. In a relational database, for instance, once a group of SQL statements execute, the results need to be stored permanently (even if the database crashes immediately thereafter). To defend against power loss, transactions (or their effects) must be recorded in a non-volatile memory.


DOM - pull the whole thing into memory and walk around inside it. Good for comparatively small chunks of XML that you want to do complex stuff with. XSLT uses DOM.

SAX - Walk the XML as it arrives watching for things as they fly past. Good for large amounts of data or comparatively simple processing.

StAX - Much like SAX but instead of responding to events found in the stream you iterate through the xml

XPath, the XML Path Language, is a query language for selecting nodes from an XML document. In addition, XPath may be used to compute values (e.g., strings, numbers, or Boolean values) from the content of an XML document. XPath was defined by the World Wide Web Consortium (W3C).[1]
A//B/*[1]

XSLT (Extensible Stylesheet Language Transformations) is a language for transforming XML documents into other XML documents,[1] or other formats such as HTML for web pages, plain text or into XSL Formatting Objects, which may subsequently be converted to other formats, such as PDF PostScript and PNG.[2]


REST security:
-Basic Authentication w/ TLS
-Oauth1.0/2.0
-Custom
-API Keys(tokens)

REST Idenpotent method:

HTTP Method	Idempotent	Safe
OPTIONS	    		yes	yes
GET					yes	yes
HEAD				yes	yes
PUT					yes	no
POST				no	no
DELETE				yes	no
PATCH				no	no

Safe methods are HTTP methods that do not modify resources.





OAuth is an open standard to authorization. OAuth provides client applications a 'secure delegated access' to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials.

http://geektimes.ru/post/77648/
OAuth — протокол для авторизованного доступа к стороннему API. OAuth позволяет скрипту Consumer-а получить ограниченный API-доступ к данным стороннего Service Provider-а, если User дает добро. Т.е. это средство для доступа к API.

SSO
Benefits of using single sign-on include:

Reducing password fatigue from different user name and password combinations
Reducing time spent re-entering passwords for the same identity
Reducing IT costs due to lower number of IT help desk calls about passwords[3]
SSO shares centralized authentication servers that all other applications and systems use for authentication purposes and combines this with techniques to ensure that users do not have to actively enter their credentials more than once.

CAS
CAS - is a single sign-on protocol for the web
The CAS protocol involves at least three parties: a client web browser, the web application requesting authentication, and the CAS server.

When the client visits an application desiring to authenticate to it, the application redirects it to CAS. CAS validates the client's authenticity, usually by checking a username and password against a database (such as Kerberos, LDAP or Active Directory).

If the authentication succeeds, CAS returns the client to the application, passing along a security ticket. The application then validates the ticket by contacting CAS over a secure connection and providing its own service identifier and the ticket. CAS then gives the application trusted information about whether a particular user has successfully authenticated.


Scalability

Scalability is ability of a system, network, or process to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth
A system whose performance improves after adding hardware, proportionally to the capacity added, is said to be a scalable system.

To scale horizontally (or scale out) means to add more nodes to a system, such as adding a new computer to a distributed software application. An example might involve scaling out from one Web server system to three. As computer prices have dropped and performance continues to increase, high-performance computing applications such as seismic analysis and biotechnology workloads have adopted low-cost "commodity" systems for tasks that once would have required supercomputers. System architects may configure hundreds of small computers in a cluster to obtain aggregate computing power that often exceeds that of computers based on a single traditional processor. The development of high-performance interconnects such as Gigabit Ethernet, InfiniBand and Myrinet further fueled this model. Such growth has led to demand for software that allows efficient management and maintenance of multiple nodes, as well as hardware such as shared data storage with much higher I/O performance. Size scalability is the maximum number of processors that a system can accommodate.[4]
To scale vertically (or scale up) means to add resources to a single node in a system, typically involving the addition of CPUs or memory to a single computer. Such vertical scaling of existing systems also enables them to use virtualization technology more effectively, as it provides more resources for the hosted set of operating system and application modules to share. Taking advantage of such resources can also be called "scaling up", such as expanding the number of Apache daemon processes currently running. Application scalability refers to the improved performance of running applications on a scaled-up version of the system.[4]


partitioning
Partitioning refers to splitting what is logically one large table into smaller physical pieces. Partitioning can provide several benefits:

Query performance can be improved dramatically in certain situations, particularly when most of the heavily accessed rows of the table are in a single partition or a small number of partitions. The partitioning substitutes for leading columns of indexes, reducing index size and making it more likely that the heavily-used parts of the indexes fit in memory.

When queries or updates access a large percentage of a single partition, performance can be improved by taking advantage of sequential scan of that partition instead of using an index and random access reads scattered across the whole table.

Seldom-used data can be migrated to cheaper and slower storage media.

One technique supported by most of the major database management system (DBMS) products is the partitioning of large tables, based on ranges of values in a key field. In this manner, the database can be scaled out across a cluster of separate database servers. Also, with the advent of 64-bit microprocessors, multi-core CPUs, and large SMP multiprocessors, DBMS vendors have been at the forefront of supporting multi-threaded implementations that substantially scale up transaction processing capacity.

Partition
A partition is a division of a logical database or its constituent elements into distinct independent parts. Database partitioning is normally done for manageability, performance or availability reasons.

Horizontal partitioning (also see shard) involves putting different rows into different tables. Perhaps customers with ZIP codes less than 50000 are stored in CustomersEast, while customers with ZIP codes greater than or equal to 50000 are stored in CustomersWest. The two partition tables are then CustomersEast and CustomersWest, while a view with a union might be created over both of them to provide a complete view of all customers.

Vertical partitioning involves creating tables with fewer columns and using additional tables to store the remaining columns.[1] Normalization also involves this splitting of columns across tables, but vertical partitioning goes beyond that and partitions columns even when already normalized. Different physical storage might be used to realize vertical partitioning as well; storing infrequently used or very wide columns on a different device, for example, is a method of vertical partitioning. Done explicitly or implicitly, this type of partitioning is called "row splitting" (the row is split by its columns). A common form of vertical partitioning is to split dynamic data (slow to find) from static data (fast to find) in a table where the dynamic data is not used as often as the static. Creating a view across the two newly created tables restores the original table with a performance penalty, however performance will increase when accessing the static data e.g. for statistical analysis.

Database can be split vertically (Partitioning) or horizontally (Sharding).

Vertically splitting (Partitioning) :– Database can be split into multiple loosely coupled sub-databases based of domain concepts. Eg:– Customer database, Product Database etc. Another way to split database is by moving few columns of an entity to one database and few other columns to another database. Eg:– Customer database , Customer contact Info database, Customer Orders database etc.

Horizontally splitting (Sharding) :– Database can be horizontally split into multiple database based on some discrete attribute. Eg:– American Customers database, European Customers database.

Transiting from single database to multiple database using partitioning or sharding is a challenging task.

Shard
A database shard is a horizontal partition of data in a database or search engine. Each individual partition is referred to as a shard or database shard. Each shard is held on a separate database server instance, to spread load.
Some data within a database remains present in all shards,[notes 1] but some only appears in a single shard. Each shard (or server) acts as the single source for this subset of data

Normalization
Database normalization is the process of organizing the attributes and tables of a relational database to minimize data redundancy.
Normalization involves refactorizing a table into smaller (and less redundant) tables but without losing information defining foreign keys in the old table referencing the primary keys of the new ones. The objective is to isolate data so that additions, deletions, and modifications of an attribute can be made in just one table and then propagated through the rest of the database using the defined foreign keys.

. Clusters which provide "lazy" redundancy by updating copies in an asynchronous fashion are called 'eventually consistent'.

Load Balance
Load balancing distributes workloads across multiple computing resources, such as computers, a computer cluster, network links, central processing units or disk drives. Load balancing aims to optimize resource use, maximize throughput, minimize response time, and avoid overload of any single resource. Using multiple components with load balancing instead of a single component may increase reliability through redundancy.

Replication
Replication in computing involves sharing information so as to ensure consistency between redundant resources, such as software or hardware components, to improve reliability, fault-tolerance, or accessibility.
The access to a replicated entity is typically uniform with access to a single, non-replicated entity. The replication itself should be transparent to an external user. Also, in a failure scenario, a failover of replicas is hidden as much as possible.

Database replication becomes difficult when it scales up.

Multi-master replication is a method of database replication which allows data to be stored by a group of computers, and updated by any member of the group. All members are responsive to client data queries. The multi-master replication system is responsible for propagating the data modifications made by each member to the rest of the group, and resolving any conflicts that might arise between concurrent changes made by different members.
Multi-master replication can be contrasted with master-slave replication, in which a single member of the group is designated as the "master" for a given piece of data and is the only node allowed to modify that data item. Other members wishing to modify the data item must first contact the master node. Allowing only a single master makes it easier to achieve consistency among the members of the group, but is less flexible than multi-master replication.
The primary purposes of multi-master replication are increased availability and faster server response time.


Distributed database
A distributed database is a database in which storage devices are not all attached to a common processing unit such as the CPU,[1] controlled by a distributed database management system
Advantages:
Management of distributed data with different levels of transparency like network transparency, fragmentation transparency, replication transparency, etc.
Increase reliability and availability
Easier expansion
Reflects organizational structure — database fragments potentially stored within the departments they relate to
Local autonomy or site autonomy — a department can control the data about them (as they are the ones familiar with it)
Protection of valuable data — if there were ever a catastrophic event such as a fire, all of the data would not be in one place, but distributed in multiple locations

RDBMS database can be scaled by having master-slave mode with read/writes on master database and only reads on slave databases. Master-Slave provides limited scaling of reads beyond which developers has to split the database into multiple databases.

Fault tolerance
Fault tolerance is the property that enables a system to continue operating properly in the event of the failure of (or one or more faults within) some of its components.



CAP theorem

Fowler interpritation:
			   ____ Consistency
			 |
			 |
Partition ----
		     |
		     | ____ Availability

Reliability:
 A system needs to be reliable, such that a request for data will consistently return the same data. In the event the daat changes or is updated, then that same request should return the new data. Users need to know that if something is written to the system, or stored, it will persist and can be relied on to be in place for future retrieval.

MApReduce
  MapReduce program is composed of a Map() procedure that performs filtering and sorting (such as sorting students by first name into queues, one queue for each name) and a Reduce() procedure that performs a summary operation (such as counting the number of students in each queue, yielding name frequencies). The "MapReduce System" (also called "infrastructure" or "framework") orchestrates the processing by marshalling the distributed servers, running the various tasks in parallel, managing all communications and data transfers between the various parts of the system, and providing for redundancy and fault tolerance.

  IO
  non-blocking I/O is a form of input/output processing that permits other processing to continue before the transmission has finished.
  Any task that depends on the I/O having completed (this includes both using the input values and critical operations that claim to assure that a write operation has been completed) still needs to wait for the I/O operation to complete, and thus is still blocked, but other processing that does not have a dependency on the I/O operation can continue.


Aggregation implies a relationship where the child can exist independently of the parent. Example: Class (parent) and Student (child). Delete the Class and the Students still exist.

Composition implies a relationship where the child cannot exist independent of the parent. Example: House (parent) and Room (child). Rooms don't exist separate to a House.

The above two are forms of containment (hence the parent-child relationships).

Dependency is a weaker form of relationship and in code terms indicates that a class uses another by parameter or return type.

Dependency is a form of association.


Memory barrier
A memory barrier, also known as a membar, memory fence or fence instruction, is a type of barrier instruction that causes a central processing unit (CPU) or compiler to enforce an ordering constraint on memory operations issued before and after the barrier instruction. This typically means that operations issued prior to the barrier are guaranteed to be performed before operations issued after the barrier.
Memory barriers are necessary because most modern CPUs employ performance optimizations that can result in out-of-order execution. This reordering of memory operations (loads and stores) normally goes unnoticed within a single thread of execution, but can cause unpredictable behaviour in concurrent programs and device drivers unless carefully controlled. The exact nature of an ordering constraint is hardware dependent and defined by the architecture's memory ordering model. Some architectures provide multiple barriers for enforcing different ordering constraints.


List<Object> lo=new List<String>()
lo.add(5)

generics


Type erasure:
The compiled generic code actually just uses java.lang.Object wherever you talk about T
Generics are checked at compile-time for type-correctness. The generic type information is then removed in a process called type erasure. For example, List<Integer> will be converted to the non-generic type List, which ordinarily contains arbitrary objects. The compile-time check guarantees that the resulting code is type-correct.
Consequent to type erasure, type parameters cannot be determined at run-time.
Java run-time environment does not need to know which parameterized type is used because the type information is validated at compile-time and is not included in the compiled code
Type parameter cannot be used in the declaration of static variables or in static methods.



currying
implicit

Definition of DONE

stop thread - boolean flag interrupted






Message queue

1. Request–reply connects a set of clients to a set of services. This is a remote procedure call and task distribution pattern.[clarification needed]
2. Publish–subscribe connects a set of publishers to a set of subscribers. This is a data distribution pattern.[clarification needed]
3. Push–pull connects nodes in a fan-out / fan-in pattern that can have multiple steps, and loops. This is a parallel task distribution and collection pattern.[clarification needed]
4. Exclusive pair connects two sockets in an exclusive pair. This is a low-level pattern for specific, advanced use cases.

There are often numerous options as to the exact semantics of message passing, including:

Durability - messages may be kept in memory, written to disk, or even committed to a DBMS if the need for reliability indicates a more resource-intensive solution.
Security policies - which applications should have access to these messages?
Message purging policies - queues or messages may have a "time to live"
Message filtering - some systems support filtering data so that a subscriber may only see messages matching some pre-specified criteria of interest
Delivery policies - do we need to guarantee that a message is delivered at least once, or no more than once?
Routing policies - in a system with many queue servers, what servers should receive a message or a queue's messages?
Batching policies - should messages be delivered immediately? Or should the system wait a bit and try to deliver many messages at once?
Queuing criteria - when should a message be considered "enqueued"? When one queue has it? Or when it has been forwarded to at least one remote queue? Or to all queues?
Receipt notification - A publisher may need to know when some or all subscribers have received a message.

Synchronous Message queue is used for RPC


A message broker is an architectural pattern for message validation, transformation and routing.[1] It mediates communication amongst applications, minimizing the mutual awareness that applications should have of each other in order to be able to exchange messages, effectively implementing decoupling.

The purpose of a broker is to take incoming messages from applications and perform some action on them. The following are examples of actions that might be taken in by the broker:

Route messages to one or more of many destinations
Transform messages to an alternative representation
Perform message aggregation, decomposing messages into multiple messages and sending them to their destination, then recomposing the responses into one message to return to the user
Interact with an external repository to augment a message or store it
Invoke Web services to retrieve data
Respond to events or errors
Provide content and topic-based message routing using the publish–subscribe pattern


JMS


Topics
In JMS a Topic implements publish and subscribe semantics. When you publish a message it goes to all the subscribers who are interested - so zero to many subscribers will receive a copy of the message. Only subscribers who had an active subscription at the time the broker receives the message will get a copy of the message.
Queues
A JMS Queue implements load balancer semantics. A single message will be received by exactly one consumer. If there are no consumers available at the time the message is sent it will be kept until a consumer is available that can process the message. If a consumer receives a message and does not acknowledge it before closing then the message will be redelivered to another consumer. A queue can have many consumers with messages load balanced across the available consumers.
So Queues implement a reliable load balancer in JMS.

Queue technique is used for one to one messaging, and it supports point to point messaging. While topic is typically used for one to many messaging and it supports public subscribe model of messaging.


n+1 one problem: DB perfomance problem when using ORM such as Hibernate when you need to query one set of results and then for all of results make another query. Example:
SELECT id, name FROM albums
SELECT id, name FROM songs WHERE album_id = 1
SELECT id, name FROM songs WHERE album_id = 2
....
Solution1:replacing the second set of N=5 queries by a single query with an IN predicate
SELECT id, title, filename FROM songs
WHERE album_id IN (1, 2, 3, 4, 5)
Solution2:Explicit “eager” fetching, using JOINs:
 SELECT
  a.id a_id,
  a.name a_name,
  s.id s_id,
  s.name s_name
FROM albums a
JOIN songs s ON s.album_id = a.id

L1 + L2 caches
L1 Cache is the cache that exists per Hibernate session, and this cache is not shared among threads. This cache makes use of Hibernate's own caching.Mainly it reduces the number of SQL queries it needs to generate within a given transaction.
L2 Cache is a cache that survives beyond a Hibernate session, and can be shared among threads. For this cache you can use either a caching implementation that comes with Hibernate like EHCache or something else like JBossCache2

persistence unit
A persistence unit defines a set of all entity classes that are managed by EntityManager instances in an application. This set of entity classes represents the data contained within a single data store.

rebase merge
If you would prefer a clean, linear history free of unnecessary merge commits, you should reach for git rebase instead of git merge when integrating changes from another branch.

On the other hand, if you want to preserve the complete history of your project and avoid the risk of re-writing public commits, you can stick with git merge.
https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview
Merge takes all the changes in one branch and merge them into another branch in one commit.
Rebase says I want the point at which I branched to move to a new starting point
Merge
Let's say you have created a branch for the purpose of developing a single feature. When you want to bring those changes back to master, you probably want merge (you don't care about maintaining all of the interim commits).

Rebase
A second scenario would be if you started doing some development and then another developer made an unrelated change. You probably want to pull and then rebase to base your changes from the current version from the repo.
 rebasing re-writes the project history by creating brand new commits for each commit in the original branch.
 The major benefit of rebasing is that you get a much cleaner project history
 rebasing loses the context provided by a merge commit—you can’t see when upstream changes were incorporated into the feature.
 The golden rule of git rebase is to never use it on public branches.

unique key primary key
Primary keys and unique keys are similar. A primary key is a column, or a combination of columns, that can uniquely identify a row. It is a special case of unique key. A table can have at most one primary key, but more than one unique key. When you specify a unique key on a column, no two distinct rows in a table can have the same value.

Primary Key
1. A primary key cannot allow null (a primary key cannot be defined on columns that allow nulls).
2. Each table cannot have more than one primary key.
3. On some RDBMS a primary key generates a clustered index by default.
Unique Key
1. A unique key can allow null (a unique key can be defined on columns that allow nulls.)
2. Each table can have multiple unique keys.
3. On some RDBMS a unique key generates a nonclustered index by default.

Clustered Index
Clustering alters the data block into a certain distinct order to match the index, resulting in the row data being stored in order. Therefore, only one clustered index can be created on a given database table. Clustered indices can greatly increase overall speed of retrieval, but usually only where the data is accessed sequentially in the same or reverse order of the clustered index, or when a range of items is selected.
Since the physical records are in this sort order on disk, the next row item in the sequence is immediately before or after the last one, and so fewer data block reads are required. The primary feature of a clustered index is therefore the ordering of the physical data rows in accordance with the index blocks that point to them. Some databases separate the data and index blocks into separate files, others put two completely different data blocks within the same physical file(s).


Cuncurency:
1 Executors, which are an enhancement over plain old threads because they are abstracted from thread pool management. They execute tasks similar to those passed to threads (in fact, instances implementing java.lang.Runnable can be wrapped). Several implementations are provided with thread pooling and scheduling strategies. Also, execution results can be fetched both in a synchronous and asynchronous manner.
2 Thread-safe queues allow for passing data between concurrent tasks. A rich set of implementations is provided with underlying data structures (such as array lists, linked lists, or double-end queues) and concurrent behaviors (such as blocking, supporting priorities, or delays).
3 Fine-grained specification of time-out delays, because a large portion of the classes found in the java.util.concurrent packages exhibit support for time-out delays. An example is an executor that interrupts tasks execution if the tasks cannot be completed within a bounded timespan.
4 Rich synchronization patterns that go beyond the mutual exclusion provided by low-level synchronized blocks in Java. These patterns comprise common idioms such as semaphores or synchronization barriers.
5 Efficient, concurrent data collections (maps, lists, and sets) that often yield superior performance in multithreaded contexts through the use of copy-on-write and fine-grained locks.
6 Atomic variables that shield developers from the need to perform synchronized access by themselves. These variables wrap common primitive types, such as integers or Booleans, as well as references to other objects.
7 A wide range of locks that go beyond the lock/notify capabilities offered by intrinsic locks, for example, support for re-entrance, read/write locking, timeouts, or poll-based locking attempts.

ForkJoinPool - executor that is dedicated to running instances implementing ForkJoinTask. ForkJoinTask objects support the creation of subtasks plus waiting for the subtasks to complete. With those clear semantics, the executor is able to dispatch tasks among its internal threads pool by “stealing” jobs when a task is waiting for another task to complete and there are pending tasks to be run.

BlockinQueue -- prducer-consumer
Deque -- each consumer has own deque, work stealing from tail of deque of other consumers

ConcurentHash map vs Hashtable(synchronized, not used anymore), vs .synchronizedMap

Latch - one time stopper

ReentrantLock
ReentrantLock behaves like synchronized and you might wonder when it's appropriate to use one or the other. Use ReentrantLock when you need timed or interruptible lock waits, non-block-structured locks (obtain a lock in one method; return the lock in another), multiple condition variables, or lock polling. Furthermore, ReentrantLock supports scalability and is useful where there is high contention among threads. If none of these factors come into play, use synchronized.

semaphore - manage permit to access smtng. Counting semapthore with count of 1 is called binary, can act as mutex.

Barriers - waits group of threads to complete,

Latches waits for EVENT, Barriers for waiting other threads
CyclicBarrier waits for fixed number of threads and then it can be re-used after the waiting threads are released.

JVM shutdown: orderly shutdown - starts all hooks, can run finalizers, make no attempt to stop or interrupt that are still running
Abrupt shutdown - on Runtiime.halt or killing JVM

Normal thread vs daemon threads differs only at in whtat happesns when they exit. On thread exit JVM check is there are normal thrreads running, if not it shutdowns, fInally block not executed

optimistic-pessimistic Concurrency:

A good way of thinking about this is that an optimistic lock is about conflict detection while a pessimistic lock
is about conflict prevention.
read-write locks

With optimistic locking both of them can make a copy of the file and edit it freely. If David is the first to finish, he can check
in his work without trouble. The concurrency control kicks in when Martin tries to commit his changes. At this
point the source code control system detects a conflict between Martin's changes and David's changes.
Martin's commit is rejected and it's up to him to figure out how to deal with the situation. With pessimistic
locking whoever checks out the file first prevents anyone else from editing it. So if Martin is first to check
out, David can't work with the file until Martin is finished with it and commits his changes


DeadLock

Can be lock-ordering deadlock. Solution: all threads acquire the lock they need in fixed GLOBAL ordering
Try to use "open calls" - call methow with no lock
Solution2: use one lock at a time
Solution3:use timed tryLock of the Lock classes

Starvation - thread is continiously denied access to recources it needs to make progress. Not recommended but can be used threads priorities.

thread-starvation deadlock - when one thread is waits for result of another task. while blocking other threads from execution

Livelock - thread while not blocked stil cannot make progress because is keeps retrying an operation that will always fail. Solutions - add retrying with random component.



Sleep vs wait:
Sleep can be only interrupted
sleeping a Thread does not release the locks it holds, while waiting releases the lock on the object that wait() is called on

A wait can be "woken up" by another thread calling notify on the monitor which is being waited on whereas a sleep cannot. Also a wait (and notify) must happen in a block synchronized on the monitor object whereas sleep does not:

Object mon = ...;
synchronized (mon) {
    mon.wait();
}
At this point the currently executing thread waits and releases the monitor. Another thread may do

synchronized (mon) { mon.notify(); }
(On the same mon object) and the first thread (assuming it is the only thread waiting on the monitor) will wake up.

You can also call notifyAll if more than one thread is waiting on the monitor - this will wake all of them up. However, only one of the threads will be able to grab the monitor (remember that the wait is in a synchronized block) and carry on - the others will then be blocked until they can acquire the monitor's lock.

Another point is that you call wait on Object itself (i.e. you wait on an object's monitor) whereas you call sleep on Thread.

Yet another point is that you can get spurious wakeups from wait (i.e. the thread which is waiting resumes for no apparent reason). You should always wait whilst spinning on some condition as follows:

synchronized {
    while (!condition) { mon.wait(); }
}

									Fail Fast Iterator	| Fail Safe Iterator
Throw ConcurrentModification Exception				Yes	| No
Clone object										No	| Yes
Memory Overhead										No	| Yes
Examples				HashMap,Vector,ArrayList,HashSet|
														|CopyOnWriteArrayList,
														|ConcurrentHashMap


╔═══════════════════╦══════════════════════╦═════════════════════════════╗
║                   ║         List         ║            Set              ║
╠═══════════════════╬══════════════════════╬═════════════════════════════╣
║     Duplicates    ║          YES         ║            NO               ║
╠═══════════════════╬══════════════════════╬═════════════════════════════╣
║       Order       ║       ORDERED        ║  DEPENDS ON IMPLEMENTATION  ║
╠═══════════════════╬══════════════════════╬═════════════════════════════╣
║ Positional Access ║         YES          ║            NO               ║
╚═══════════════════╩══════════════════════╩═════════════════════════════╝

HashSet (unordered)
LinkedHashSet (ordered)
TreeSet (sorted by natural order or by provided comparator)

GC
There are four kinds of GC roots in Java:

1.Local variables are kept alive by the stack of a thread. This is not a real object virtual reference and thus is not visible. For all intents and purposes, local variables are GC roots.
2.Active Java threads are always considered live objects and are therefore GC roots. This is especially important for thread local variables.
3.Static variables are referenced by their classes. This fact makes them de facto GC roots. Classes themselves can be garbage-collected, which would remove all referenced static variables. This is of special importance when we use application servers, OSGi containers or class loaders in general. We will discuss the related problems in the Problem Patterns section.
4.JNI References are Java objects that the native code has created as part of a JNI call. Objects thus created are treated specially because the JVM does not know if it is being referenced by the native code or not. Such objects represent a very special form of GC root, which we will examine in more detail in the Problem Patterns section below.

GC types
There are 5 GC types.
1 Serial GC
2 Parallel GC
3 Parallel Old GC (Parallel Compacting GC)
4 Concurrent Mark & Sweep GC  (or "CMS")
5 Garbage First (G1) GC

Cuncurent GC - works cuncurently with app
Parallel GC - uses multiple CPUs to perform gc

GC is Conservative when it unaware of some references or not sure if field is reference or not
GC is Precise when it can cull identify all object references

compacting - remove fragmantation of heap, relocate, remap

— Throwable и Exception и все их наследники (за исключением наследников Error-а и RuntimeException-а) — checked
— Error и RuntimeException и все их наследники — unchecked

GC:
When Eden is full - minor GC is going
When Tenured(old_) full - major GC
The Permanent Generation is a special case, it contains objects that are needed by the JVM that are not necessarily represented in your program, for example objects that represent classes and methods.
GS algorithm:
Serial - user when one core CPU(amazon micro instance), smallest overhead
Parallel - usually N times faster then serial, better throughtput
CMS - in young - paralel, old - mostly concurent, old is fragmented, smaller GC pause then parallel, throughtput is lower, better when enought heap size
G1 - new, Java8 - monplithis STW YoungGen, mostly concurent oldGen marker, STW mostly instemental compacting oldgen, fall back to monolithic stop-the-world

GC stages:
mark, sweep, compact

GC pause is NOT depends on Xmx(heap size)

GC efficency depends on empty heap size

STW - stop the world time

Memory model:

-----HEAP----------------------------PermGen----Thread
----Young gen-------------ld gen-----
Eden--Survivor1-surivivor2 = YG


PermGen is replaced with Metaspace in JDK8, which is very similar. The main difference is that Metaspace can expand at runtime.

A new flag is available (MaxMetaspaceSize), allowing you to limit the amount of native memory used for class metadata. If you don’t specify this flag, the Metaspace will dynamically re-size depending of the application demand at runtime. Size unbounded (default) -  system memory is the limit.

висота дерева
бинарнй пошук
реверс стрічки
public static String reverse(String orig)
{
    char[] s = orig.toCharArray();
    int n = s.length;
    int halfLength = n / 2;
    for (int i=0; i<halfLength; i++)
    {
        char temp = s[i];
        s[i] = s[n-1-i];
        s[n-1-i] = temp;
    }
    return new String(s);
}
квик сорт

Arrays merge. Implement merge step of merge sort algorithm. For example:
Input: 2 sorted arrays, [5 6 7 8 13 14 15] and [2 3 4 9 11].
Output: merged array, [2 3 4 5 6 7 8 9 11 13 14 15].


Code Metrics
By MS:
-Maintainability Index
-Cyclomatic Complexity
-Depth of Inheritance
-Class Coupling   !!!Good software design dictates that types and methods should have high cohesion and low coupling. !!!
-Lines of Code
-Code coverage


safe publication

memory strike
type cohesion
cohesion refers to the degree to which the elements of a module belong together.
High cohesion often correlates with loose coupling, and vice versa

Transaction isolation:
Isolation Level      Dirty Read Unrepeatable Read Phantom
Read Uncommitted     Yes        Yes               Yes
Read Committed       No         Yes               Yes
Repeatable Read      No         No 				  Yes
Serializable		 No 		No 				  No

Serializable[edit]
This is the highest isolation level.
With a lock-based concurrency control DBMS implementation, serializability requires read and write locks (acquired on selected data) to be released at the end of the transaction. Also range-locks must be acquired when a SELECT query uses a ranged WHERE clause, especially to avoid the phantom reads phenomenon (see below).
When using non-lock based concurrency control, no locks are acquired; however, if the system detects a write collision among several concurrent transactions, only one of them is allowed to commit. See snapshot isolation for more details on this topic.
Repeatable reads[edit]
In this isolation level, a lock-based concurrency control DBMS implementation keeps read and write locks (acquired on selected data) until the end of the transaction. However, range-locks are not managed, so phantom reads can occur.
Read committed[edit]
In this isolation level, a lock-based concurrency control DBMS implementation keeps write locks (acquired on selected data) until the end of the transaction, but read locks are released as soon as the SELECT operation is performed (so the non-repeatable reads phenomenon can occur in this isolation level, as discussed below). As in the previous level, range-locks are not managed.
Putting it in simpler words, read committed is an isolation level that guarantees that any data read is committed at the moment it is read. It simply restricts the reader from seeing any intermediate, uncommitted, 'dirty' read. It makes no promise whatsoever that if the transaction re-issues the read, it will find the same data; data is free to change after it is read.
Read uncommitted[edit]
This is the lowest isolation level. In this level, dirty reads are allowed, so one transaction may see not-yet-committed changes made by other transactions.
Since each isolation level is stronger than those below, in that no higher isolation level allows an action forbidden by a lower one, the standard permits a DBMS to run a transaction at an isolation level stronger than that requested (e.g., a "Read committed" transaction may actually be performed at a "Repeatable read" isolation level).

materialized view is a database object that contains the results of a query. For example, it may be a local copy of data located remotely, or may be a subset of the rows and/or columns of a table or join result, or may be a summary using an aggregate function.

Materialized views are disk based and are updated periodically based upon the query definition.
Views are virtual only and run the query definition each time they are accessed.

https://en.wikipedia.org/wiki/Flyweight_pattern

System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic.

GOF

Creational patterns

	Abstract factory (recognizeable by creational methods returning the factory itself which in turn can be used to create another abstract/interface type):
		xml.parsers.DocumentBuilderFactory#newInstance()
		xml.transform.TransformerFactory#newInstance()
		xml.xpath.XPathFactory#newInstance()

	Builder (recognizeable by creational methods returning the instance itself)
		java.lang.StringBuilder#append() (unsynchronized)
		java.lang.StringBuffer#append() (synchronized)
		java.nio.ByteBuffer#put() (also on CharBuffer, ShortBuffer, IntBuffer, LongBuffer, FloatBuffer and DoubleBuffer)
		javax.swing.GroupLayout.Group#addComponent()
		All implementations of java.lang.Appendable

	Factory method (recognizeable by creational methods returning an implementation of an abstract/interface type)
		java.util.Calendar#getInstance()
		java.util.ResourceBundle#getBundle()
		java.text.NumberFormat#getInstance()
		java.nio.charset.Charset#forName()
		java.net.URLStreamHandlerFactory#createURLStreamHandler(String) (Returns singleton object per protocol)

	Prototype (recognizeable by creational methods returning a different instance of itself with the same properties)
		java.lang.Object#clone() (the class has to implement java.lang.Cloneable)

	Singleton (recognizeable by creational methods returning the same instance (usually of itself) everytime)
		java.lang.Runtime#getRuntime()
		java.awt.Desktop#getDesktop()
		java.lang.System#getSecurityManager()

Structural patterns

	Adapter (recognizeable by creational methods taking an instance of different abstract/interface type and returning an implementation of own/another abstract/interface type which decorates/overrides the given instance)
		java.util.Arrays#asList()
		java.io.InputStreamReader(InputStream) (returns a Reader)
		java.io.OutputStreamWriter(OutputStream) (returns a Writer)
		javax.xml.bind.annotation.adapters.XmlAdapter#marshal() and #unmarshal()

	Bridge (recognizeable by creational methods taking an instance of different abstract/interface type and returning an implementation of own abstract/interface type which delegates/uses the given instance)

	Composite (recognizeable by behavioral methods taking an instance of same abstract/interface type into a tree structure)
		java.awt.Container#add(Component) (practically all over Swing thus)

	Decorator (recognizeable by creational methods taking an instance of same abstract/interface type which adds additional behaviour)
		All subclasses of java.io.InputStream, OutputStream, Reader and Writer have a constructor taking an instance of same type.
		java.util.Collections, the checkedXXX(), synchronizedXXX() and unmodifiableXXX() methods.
		javax.servlet.http.HttpServletRequestWrapper and HttpServletResponseWrapper

	Facade (recognizeable by behavioral methods which internally uses instances of different independent abstract/interface types)

	Flyweight (recognizeable by creational methods returning a cached instance, a bit the "multiton" idea)
		java.lang.Integer#valueOf(int) (also on Boolean, Byte, Character, Short, Long and BigDecimal)

	Proxy (recognizeable by creational methods which returns an implementation of given abstract/interface type which in turn delegates/uses a different implementation of given abstract/interface type)
		java.lang.reflect.Proxy
		java.rmi.*, the whole API actually.

Behavioral patterns
	Chain of responsibility (recognizeable by behavioral methods which (indirectly) invokes the same method in another implementation of same abstract/interface type in a queue)
		java.util.logging.Logger#log()
		javax.servlet.Filter#doFilter()

	Command (recognizeable by behavioral methods in an abstract/interface type which invokes a method in an implementation of a different abstract/interface type which has been encapsulated by the command implementation during its creation)
		All implementations of java.lang.Runnable
		All implementations of javax.swing.Action

	Interpreter (recognizeable by behavioral methods returning a structurally different instance/type of the given instance/type; note that parsing/formatting is not part of the pattern, determining the pattern and how to apply it is)
		java.util.Pattern
		java.text.Normalizer

	Iterator (recognizeable by behavioral methods sequentially returning instances of a different type from a queue)
		All implementations of java.util.Iterator (thus among others also java.util.Scanner!).
		All implementations of java.util.Enumeration

	Mediator (recognizeable by behavioral methods taking an instance of different abstract/interface type (usually using the command pattern) which delegates/uses the given instance)
		java.util.Timer (all scheduleXXX() methods)
		java.util.concurrent.Executor#execute()
		java.util.concurrent.ExecutorService (the invokeXXX() and submit() methods)
		java.util.concurrent.ScheduledExecutorService (all scheduleXXX() methods)
		java.lang.reflect.Method#invoke()

	Memento (recognizeable by behavioral methods which internally changes the state of the whole instance)
		java.util.Date (the setter methods do that, Date is internally represented by a long value)
		All implementations of java.io.Serializable
		All implementations of javax.faces.component.StateHolder

	Observer (or Publish/Subscribe) (recognizeable by behavioral methods which invokes a method on an instance of another abstract/interface type, depending on own state)
		java.util.Observer/java.util.Observable (rarely used in real world though)
		All implementations of java.util.EventListener (practically all over Swing thus)
		javax.servlet.http.HttpSessionBindingListener
		javax.servlet.http.HttpSessionAttributeListener


	State (recognizeable by behavioral methods which changes its behaviour depending on the instance's state which can be controlled externally)
		javax.faces.lifecycle.LifeCycle#execute() (controlled by FacesServlet, the behaviour is dependent on current phase (state) of JSF lifecycle)

	Strategy (recognizeable by behavioral methods in an abstract/interface type which invokes a method in an implementation of a different abstract/interface type which has been passed-in as method argument into the strategy implementation)
		java.util.Comparator#compare(), executed by among others Collections#sort().
		javax.servlet.http.HttpServlet, the service() and all doXXX() methods take HttpServletRequest and HttpServletResponse and the implementor has to process them (and not to get hold of them as instance variables!).
		javax.servlet.Filter#doFilter()

	Template method (recognizeable by behavioral methods which already have a "default" behaviour definied by an abstract type)
		All non-abstract methods of java.io.InputStream, java.io.OutputStream, java.io.Reader and java.io.Writer.
		All non-abstract methods of java.util.AbstractList, java.util.AbstractSet and java.util.AbstractMap.
		javax.servlet.http.HttpServlet, all the doXXX() methods by default sends a HTTP 405 "Method Not Allowed" error to the response. You're free to implement none or any of them.

	Visitor (recognizeable by two different abstract/interface types which has methods definied which takes each the other abstract/interface type; the one actually calls the method of the other and the other executes the desired strategy on it)
		java.nio.file.FileVisitor and SimpleFileVisitor


Proxy could be used when you want to lazy-instantiate an object, or hide the fact that you're calling a remote service, or control access to the object.

Decorator is also called "Smart Proxy." This is used when you want to add functionality to an object, but not by extending that object's type. This allows you to do so at runtime.

Adapter is used when you have an abstract interface, and you want to map that interface to another object which has similar functional role, but a different interface.

Bridge is very similar to Adapter, but we call it Bridge when you define both the abstract interface and the underlying implementation. I.e. you're not adapting to some legacy or third-party code, you're the designer of all the code but you need to be able to swap out different implementations.



Patterns

Enterprise patterns:
Decoupling using app layers: data source, logic, presentation, etc


 Domain Model
 Service Layer(security, transactions, etc)
 Remote Facade
  Data Transfer Object
  Unit of Work
   Class Table Inheritance
    Active Record - logic with data
     Data Mapper -  separates the domain objects and the database from each other
   Gateway - one class per database table
    Unit of Work  - keeps track of all objects read from the database, together with all objects modified in any way
    Lazy load
     Foreign Key Mapping
     Association Table Mapping
     Serialized LOB
     Inheritance in DB:
      1 Single Table Inheritance
      2 Concrete Table Inheritance
      3 Class Table Inheritance
      Metadata Mapping - used in ORMs
      Repository
   WEB patterns
     Model View Controller
     Transform View (XSLT)
     Template View (JSP)

   Session:
   	 Server Session State
   	 Client Session State
   	 Database Session State

   	Remote Facade returns
   	Data Transfer Object


Enterprise patterns:
	Integration Styles[edit]
		File Transfer
		Shared Database
		Remote Procedure Invocation
		Messaging
	Integration Types[edit]
		Informationportal
		Data Replication
		Shared Business Function
		Service Oriented Architecture
		Distributed Business Process
		Business-to-Business Integration
		Tightly Coupled Interaction vs. Loosely Coupled Interaction
	Messaging[edit]
		Message Channel
		Message
		Pipes and Filters
		Message Router
		Message Translator
		Message Endpoint

Distributed design patterns
	Distributed communication patterns(RPC, CORBA)
	Event driven (Akka, Java Swing) - An event-driven system typically consists of event emitters (or agents), event consumers (or sinks), and event channels.
	MapReduce
	Bulk synchronous parallel
	Remote Session[1]



Reactive manifesto
Responsive: The system responds in a timely manner if at all possible. Responsiveness is the cornerstone of usability and utility, but more than that, responsiveness means that problems may be detected quickly and dealt with effectively. Responsive systems focus on providing rapid and consistent response times, establishing reliable upper bounds so they deliver a consistent quality of service. This consistent behaviour in turn simplifies error handling, builds end user confidence, and encourages further interaction.
Resilient: The system stays responsive in the face of failure. This applies not only to highly-available, mission critical systems — any system that is not resilient will be unresponsive after a failure. Resilience is achieved by replication, containment, isolation and delegation. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures.
Elastic: The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them. Reactive Systems support predictive, as well as Reactive, scaling algorithms by providing relevant live performance measures. They achieve elasticity in a cost-effective way on commodity hardware and software platforms.
Message Driven: Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages. Employing explicit message-passing enables load management, elasticity, and flow control by shaping and monitoring the message queues in the system and applying back-pressure when necessary. Location transparent messaging as a means of communication makes it possible for the management of failure to work with the same constructs and semantics across a cluster or within a single host. Non-blocking communication allows recipients to only consume resource while active, leading to less system overhead.


GoF Patterns:

Creational patterns are ones that create objects for you, rather than having you instantiate objects directly. This gives your program more flexibility in deciding which objects need to be created for a given case.
	Abstract factory pattern groups object factories that have a common theme.
	Builder pattern constructs complex objects by separating construction and representation.
	Factory method pattern creates objects without specifying the exact class to create.
	Prototype pattern creates objects by cloning an existing object.
	Singleton pattern restricts object creation for a class to only one instance.

Structural[edit]
These concern class and object composition. They use inheritance to compose interfaces and define ways to compose objects to obtain new functionality.
	Adapter allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class.
	Bridge decouples an abstraction from its implementation so that the two can vary independently.
	Composite composes zero-or-more similar objects so that they can be manipulated as one object.
	Decorator dynamically adds/overrides behaviour in an existing method of an object.
	Facade provides a simplified interface to a large body of code.
	Flyweight reduces the cost of creating and manipulating a large number of similar objects.
	Proxy provides a placeholder for another object to control access, reduce cost, and reduce complexity.

Behavioral[edit]
Most of these design patterns are specifically concerned with communication between objects.
	Chain of responsibility delegates commands to a chain of processing objects.
	Command creates objects which encapsulate actions and parameters.
	Interpreter implements a specialized language.
	Iterator accesses the elements of an object sequentially without exposing its underlying representation.
	Mediator allows loose coupling between classes by being the only class that has detailed knowledge of their methods.
	Memento provides the ability to restore an object to its previous state (undo).
	Observer is a publish/subscribe pattern which allows a number of observer objects to see an event.
	State allows an object to alter its behavior when its internal state changes.
	Strategy allows one of a family of algorithms to be selected on-the-fly at runtime.
	Template method defines the skeleton of an algorithm as an abstract class, allowing its subclasses to provide concrete behavior.
	Visitor separates an algorithm from an object structure by moving the hierarchy of methods into one object.