Java колекции обзор

Интерфейс Collection содержит несколько методов, которые не реализуют некоторые его наследники, они если вызвать на них этот метод выкинут исключение.

Откат локальных ненужных комитов

git reset --hard HEAD~2

Collections.asList

Метод не далает копию переданного в него массива, а хранит именно элементы массива. Изменения в списке сразу же видны в массиве и наоборот.
Результат на выходе из метода не ялвяется реализацией листа, потому что методы add, remove не работают, это дает нам неизменяемость размера массива, что является правильным с точки зрения того, что этот лист это обвертка вокруг существующего массива.
Фактически на выходе у нас java.util.Arrays$ArrayList

Передать параметр с контроллера в джееспе

response.setRenderParameter("parameter-name", "value");

<%@ taglib uri="http://java.sun.com/portlet" prefix="liferay-portlet" %>

...
<%= renderRequest.getParameter("parameter-name") %>

Смотреть/получать удаленные бранчи

Увидеть все бранчи(и удаленные и локальные):

$ git branch -a
* master
  origin/HEAD
  origin/master
  origin/v1.0-stable
  origin/experimental

Просто посмотреть, что там на удаленном:

 git checkout origin/experimental

Получить удаленный с которым можно полноценно работать:

$ git checkout -b experimental origin/experimental

Java collections filtering

http://guidogarcia.net/blog/2011/10/29/java-different-ways-filter-collection/

Переименование бранча

git branch -m  

Reentrancy

Reentrancy - характеристика Intrinsic Lock в Java, он же Monitor Lock, он же Implicit Java Mutex.
Этот вид лока обеспечивается synchronized методами и блоками.
Так вот Reentrancy это обеспечение возможности получить потоку лок еще раз, если он уже им владеет. Так можно вызывать из синхронизированного метода синхронизированный метод этого же класса для одного и того же обьекта. Это блокировка по потоку, а не по вызову (как реализация мютекса в POSIX threads).
Внутренняя реализация подобного механизма следующая: лок содержит ссылку на поток, который сейчас им владеет, при этом в нем есть счетчик обладений, который каждый раз инкриментируется, когда поток повторно им овладевает, когда этот счетчик обнуляется, то тогда и удаляется ссылка на поток - и лок считается свободным.

Проблемы конкурентности в Java

1. Race condition (состояние гонки). В этом случае правильности исчисления зависит от случайного стечения обстоятельств в последовательности выполнения частей кода потока.
Это понятие связано с data race и часто между ними ставят равно, но это частный случай  -- в ситуации когда поле пишется и читается разными потоками, при этом каждый считает, что только у него есть доступ к этому полю и никак не ожидает, что оно может измениться извне.


Операции с полями, которые подлежат влиянию из разных потоков, типа check-then-act и read-modify-write всегда должны быть атомарными. Пример первого, когда у нас поле определенного значения мы должны выполнить соответствующие операции, пока мы проверили и начали что-то выполнять оно поменялось, а мы все еще выполняем. Второй вид -это инкримент, пока мы получили значение изменили его, оно уже изменилось, а мы записали результат основанный на старом значении.

Вложенные классы

Бывают двух основных типов:
static nested classes - это больше похоже на обычный класс, который просто вложен в другой для удобства их совместной поставки. Такой класс не имеет доступа к скрытым методам и полям внешнего класса. Инстанциируется таким образом:

OuterClass.StaticNestedClass nestedObject = new OuterClass.StaticNestedClass();

inner classes -- эти друзья вяжутся к инстациям своего внешнего класса, они имеют доступ ко всем его полям и методам вне зависимости от их области видимости. Такие классы могут быть приватными, протектыд, паблик и пекидж прайвет. Вот так они создаются:

OuterClass.InnerClass innerObject = outerObject.new InnerClass();

local classes -- которые объявлены внутри конструктора или метода, и соответственно могут использоваться только внутри них.

anonymous inner classes -- эти классы создаются обычно из реализации какого-то интерфейса налету.


Рефлексия в яве тоже позволяет понимать с какием классом мы работаем, а также получать то что находится в нем внутри кроме полей и методов:

java.lang.Class
- getEnclosingClass
-getEnclosingConstructor
-getEnclosingMethod
-isAnonymousClass
-isLocalClass
-isMemberClass

-server ключ

Этот ключ включает множество оптимизаций, если мы разрабатываем серверное приложение, то всегда для тестов и дебага мы должны запускать наше проложение с таким ключем, потому что мы можем столкнуться в работающем приложение с проблемами, которые мы не отловили, ведь оно будет запущено с таким ключем.

Mutex

Mutex - mutual exclusion, или взаимное исключение, это вид семафора, которым в одно и тоже время может владеть только один поток, при этом все запросившие этот семафор потоки сохраняются в стеке мютекса, и контроль передается в порядке обращения по мере освобождения.

Представитель мютекса в джава это synchronized блок и метод, только вот блокировака налаживается на поток, а не на вызов как в POSIX mutex, в джава же один и тот же поток может захватывать уже захваченный собой intrinstic lock(так называется этот мютекс в терминологии ява), просто счетчик захвата этого лока увеличивается. Лок считается свободным когда у него счетчик==0, в этот момент вытирается ссылка на тред и он считается свободным.

volatile in C/C++

Это ключевое слово говоприт комплятору, что отмеченные переменные не нужно оптимизировать с его точки зрения, то есть ассембли-кода будет намного больше -- никаких оптимизаций не будет применено. Это полезно в случае, когда значение переменной меняется с наружи.

ThreadLocal

Это хештаблица, которая позволяет хранить значение указанного типа Т для каждого потока свое. Например если у нас есть класс, инстанцию которого мы разделяем между несколькими потоками, но нам в нем нужно поле, которое будет иметь свою копию для каждого потока.

Доступно описан смысл с упоминанием подводных камней здесь:
http://samolisov.blogspot.com/2011/04/threadlocal.html

volatile

Locking гарантирует и видимость и атомарность, volalite -- только видимость.

Взято из: http://www.askdev.ru/java/1512/volatile/ :

Данный модификатор актуален в многопоточных приложениях, гарантирует что
- Операции записи и чтения (выполняемые потоками) происходят напрямую с основной памятью. (в связи с вопросами эффективности каждый поток может использовать свою "локальную память").
- Операции записи, чтения значений длиной 64 бит происходят атомарно (данная операция может быть представлена как две 32-х битовые операции, что может вылиться в неприятности для не volatile переменных)
- с Java 1.5. При обращении к volatile переменной происходит синхронизация для всех локальных переменных потока с основной памятью
- с Java 1.5. Операции, стоящие в коде перед операцией записи в переменную volatile, должны быть выполнены раньше, то есть оптимизатор JVM не имеет права переставить их местами. Проблема напрямую связана с double-checking idiom, подробней можно посмотреть здесь
http://jeremymanson.blogspot.com/2008/05/double-checked-locking.html
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Безопасно использовать:
- Записываемое значение не зависит от текущего
- Не учавствует в инвариантах с другими переменными

 Brian Goetz достаточно ясно сформулировал несколько паттернов безопасного использования volatile в своей статье
http://www.ibm.com/developerworks/java/library/j-jtp06197.html

http://en.wikipedia.org/wiki/Volatile_variable

Неожиданный подводный камень. 
JMV обеспечивает потокобезопасноть только для атомарных операций - чтение и запись переменной.
Так что инкрмент это потоконебезопасная операция

myVolatileVar++;

Чтобы сделать это потокобезопасным нужно:

int temp = 0;
synchronize( myVolatileVar ) {
  temp = myVolatileVar;
} 
temp++; 
synchronize( myVolatileVar ) {
  myVolatileVar = temp;
}

Подобный код можно не писать, а пользоваться атомиками из пакета java.util.concurrent.atomic

Куда двигаться в изучении многопоточности

Взято с http://www.rsdn.ru/forum/java/3622844.1

Все проекты связанные с многопоточностью я бы разделил на 3 класса: использующие многопоточность, основанные на многопоточности и те, которые и есть сама многопоточность. К первому классу("использующие") я бы отнес проекты, которые предполагают работу в многопоточной среде. Пример: есть класс BlaBlaBlaFactory, в документации необходимо указать, может ли эта фабрика использоваться одновременно несколькими потоками или нет. Если нет, то сделать ее потокобезопасной с помощью ReentrantLock. Ко второму классу ("основанные на") я бы отнес проекты, в которых использование нескольких потоков является одним из ключевых моментов. Пример: многопоточный кодек видео формата H.264. К третьему классу ("являются ей") я бы отнес проекты, в корне что-то меняющие в отношении потоков. Пример: написание runtime-среды для языка Scala (на Java) с реализацией легковесных потоков и своеобразной моделью памяти.
Так вот, дело в том, что разработчик зачастую указывает на свое знание java concurrency имея в виду первый уровень. Компания же может иметь в виду второй (написание высоконагруженного сервера, написание физического/AI ядра 3D-шутера, написание OLAP-системы — во всех случаях с требованием ОДИН запрос пользователя обрабатывать в НЕСКОЛЬКО потоков). Иногда разработчики не знают про существование уровней выше первого. Особенную лепту в это вносят книги вводного или обзорного характера.
Ниже я привожу ряд вопросов с гипотетического собеседования по java concurrency, относящиеся как к первому так и ко второму уровню. Надеюсь кому-то они покажут направление, в котором возможно развиваться. 
Как и на всяком собеседовании, не предполагается, что интервьюируемый ответит на все вопросы. Но предполагается, что опрашиваемый по-крайней мере ознакомлен с тематикой. Кроме того определение того 1) что кандидат знает; 2) о чем слышал; 3) о чем не слышал; позволяет составить о нем более полное мнение.

1. Назовите различия между Collections.synchronizedMap(new HashMap()) и ConcurrentHashMap.
2. Что такое кооперативная многозадачность и она ли ли в Java. Если да, то какие преимущества. Если нет, то какая тогда в Java?

java.util.concurrecy

В синхронном программировании с задачей параллельности могут справляться процессы, либо потоки/среды.
Процессы -- приложения загруженные в память, они имеют выделенную под свои нужды оперативную память, которая доступна только им, а также если овладевают ресурсом, то другие процессы не имеют доступа к ним.
Потоки -- сущности внутри процесса, которые могут разделять между собой одну память процесса, а также ресурсы, которыми он овладел. За тем, чтобы не было проблем (взаимовмешательств, согласованности хранения в памяти) нужно следить за этим из приложения.