Зри в корень: java.lang.Object

March 27, 2019 by delfin

В Java в вершине иерархии классов лежит класс java.lang.Object. Лежит и лежит, долгое время я им совсем не интересовался.

На собеседованиях часто спрашивают, какие в нем есть методы, поэтому они как-то сами собой выучились. Пришло время посмотреть на этот класс более внимательно. Первый вопрос, который у меня возник, есть ли вообще в исходниках Java класс java.lang.Object. Он же ведь необычный, он вполне может быть жестко зашит в реализацию, как самый верхний.

Однако, такой класс есть и я приведу тут исходники java/lang/Object.java, опустив javadoc, и попытаюсь пролить свет на некоторые моменты связанные с реализацией jvm:

package java.lang;

public class Object {

    private static native void registerNatives();
    static {
        registerNatives();
    }

    public final native Class<?> getClass();

    public native int hashCode();

    public boolean equals(Object obj) {
        return (this == obj);
    }

    protected native Object clone() throws CloneNotSupportedException;

    public String toString() {
        return getClass().getName() + "@" + Integer.toHexString(hashCode());
    }

    public final native void notify();

    public final native void notifyAll();

    public final native void wait(long timeout) throws InterruptedException;

    public final void wait(long timeout, int nanos) throws InterruptedException {
        if (timeout < 0) {
            throw new IllegalArgumentException("timeout value is negative");
        }

        if (nanos < 0 || nanos > 999999) {
            throw new IllegalArgumentException(
                                "nanosecond timeout value out of range");
        }

        if (nanos >= 500000 || (nanos != 0 && timeout == 0)) {
            timeout++;
        }

        wait(timeout);
    }

    public final void wait() throws InterruptedException {
        wait(0);
    }

    protected void finalize() throws Throwable { }
}

package java.lang;

public class Object {

private static native void registerNatives();

static {

registerNatives();

}

public final native Class<?> getClass();

public native int hashCode();

public boolean equals(Object obj) {

return (this == obj);

}

protected native Object clone() throws CloneNotSupportedException;

public String toString() {

return getClass().getName() + "@" + Integer.toHexString(hashCode());

}

public final native void notify();

public final native void notifyAll();

public final native void wait(long timeout) throws InterruptedException;

public final void wait(long timeout, int nanos) throws InterruptedException {

if (timeout < 0) {

throw new IllegalArgumentException("timeout value is negative");

}

if (nanos < 0 || nanos > 999999) {

throw new IllegalArgumentException(

"nanosecond timeout value out of range");

}

if (nanos >= 500000 || (nanos != 0 && timeout == 0)) {

timeout++;

}

wait(timeout);

}

public final void wait() throws InterruptedException {

wait(0);

}

protected void finalize() throws Throwable { }

}

Что бы я хотел отметить в этом коде?

Всего в Object 11 публичных методов, 5 обычных и 6 с нативной реализацией.

Рассмотрим обычные методы, так как их код уже доступен.

По дефолту все объекты сравниваются на равенство ссылок. Мне, кстати, в своем время понравилась шутка про то, что для того, чтобы запутать C++ программистов указатели в Java названы ссылками.

public boolean equals(Object obj) {
    return (this == obj);
}

public boolean equals(Object obj) {

return (this == obj);

}

toString тоже не содержит ничего необычного, кроме разве того, что hashCode() преобразуется в шестнадцатеричную строку. И если бы apangin не написал, что нынче как только нельзя посчитать hashCode, я бы подумал, что раньше Java программисты могли найти свой объект по hashCode, т.к. он был не чем иным как ссылкой. Те 32 битные времена для многих прошли, и теперь даже не знаю, есть ли смысл в toString() выводить hashCode.

public String toString() {
    return getClass().getName() + "@" + Integer.toHexString(hashCode());
}

public String toString() {

return getClass().getName() + "@" + Integer.toHexString(hashCode());

}

Кроме того, что wait относится к примитивам обеспечивающим многопоточность, хочется отметить бесполезность параметра nanos.

В некоторых случаях он просто добавляет одну милисекунду. Интересно, это закладка на будущее или уже есть системы в которых у wait(long timeout, int nanos) другая реализация.

public final void wait(long timeout, int nanos) throws InterruptedException {
    if (timeout < 0) {
        throw new IllegalArgumentException("timeout value is negative");
    }

    if (nanos < 0 || nanos > 999999) {
        throw new IllegalArgumentException(
                            "nanosecond timeout value out of range");
    }

    if (nanos >= 500000 || (nanos != 0 && timeout == 0)) {
        timeout++;
    }

    wait(timeout);
}

public final void wait() throws InterruptedException {
    wait(0);
}

public final void wait(long timeout, int nanos) throws InterruptedException {

if (timeout < 0) {

throw new IllegalArgumentException("timeout value is negative");

}

if (nanos < 0 || nanos > 999999) {

throw new IllegalArgumentException(

"nanosecond timeout value out of range");

}

if (nanos >= 500000 || (nanos != 0 && timeout == 0)) {

timeout++;

}

wait(timeout);

}

public final void wait() throws InterruptedException {

wait(0);

}

Завершает парад обычных методов в java.lang.Object:

protected void finalize() throws Throwable { }

1	protected void finalize() throws Throwable { }

Этот метод ничего не делает, и есть куча материалов о том, что следует избегать его использования finalize и Finalizer, смысл finalize.

Теперь посмотрим на на java/lang/Object.class Например, мне интересно что в нем указано в качестве супер класса. Находим в установленном jre или jdk rt.jar, распаковываем:

jar -xf rt.jar

1 2	jar -xf rt.jar

И видим, что в super class у него прописаны 00 00, интересно что будет, если руками создать class файл без супер класса.
Я взял Hello.class из моей предыдущей заметки.

Открыл его в vim и заменил содержание буфера на hex дамп vim.wikia.com/wiki/Hex_dump:

:%!xxd

:%!xxd

Поразился мощи vim редактора. Быстренько нашел байты для super_class. Напомню, они лежат согласно спецификации через 4 байта после окончания constant_pool. Конец constant_pool ищется по тегу строки 00 01 и последовательности не нулевых байтов, когда начинаются нули идут другие разделы constant_pool. Для других class файлов это может быть не так, но в моем случае сработало.
Возвращаемся обратно к бинарному виду:

:%!xxd -r

:%!xxd -r

Сохраняем изменения. Запускаем наше поправленное приложение:

java -cp classes/ hello.App

Error: A JNI error has occurred, please check your installation and try again
Exception <span class="hljs-keyword">in</span> thread <span class="hljs-string">"main"</span> java.lang.ClassFormatError: Invalid superclass index 0 <span class="hljs-keyword">in</span> class file hello/App
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
    at java.net.URLClassLoader.access<span class="hljs-variable">$100</span>(URLClassLoader.java:73)
    at java.net.URLClassLoader<span class="hljs-variable">$1</span>.run(URLClassLoader.java:368)
    at java.net.URLClassLoader<span class="hljs-variable">$1</span>.run(URLClassLoader.java:362)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher<span class="hljs-variable">$AppClassLoader</span>.loadClass(Launcher.java:331)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)

java -cp classes/ hello.App

Error: A JNI error has occurred, please check your installation and try again

Exception in thread "main" java.lang.ClassFormatError: Invalid superclass index 0 in class file hello/App

at java.lang.ClassLoader.defineClass1(Native Method)

at java.lang.ClassLoader.defineClass(ClassLoader.java:760)

at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)

at java.net.URLClassLoader.access$100(URLClassLoader.java:73)

at java.net.URLClassLoader$1.run(URLClassLoader.java:368)

at java.net.URLClassLoader$1.run(URLClassLoader.java:362)

at java.security.AccessController.doPrivileged(Native Method)

at java.net.URLClassLoader.findClass(URLClassLoader.java:361)

at java.lang.ClassLoader.loadClass(ClassLoader.java:424)

at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)

at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)

Ошибка, да еще не какая-нибудь, а выброшенная из нативного метода во время загрузки классов. Пойдем разбираться, за одно может поймем как выбрасывать такие ошибки.

Нам нужны исходники jdk. Я выбрал OpenJDK для исследования. Будем качать их отсюда:

hg.openjdk.java.net/jdk8/jdk8

И хранить в Меркурии:

hg clone hg.openjdk.java.net/jdk8/jdk8

Но на этом не всё.

Надо еще запустить:

./get_source.sh

1	./get_source.sh

И подождать. Отлично, исходники скачались и можно искать нашу ошибку. Я делаю это grep-ом:

grep -nr 'Invalid superclass index' *

hotspot/src/share/vm/classfile/classFileParser.cpp:3095:                   "Invalid superclass index %u in class file %s",
hotspot/src/share/vm/classfile/classFileParser.cpp:3100:                   "Invalid superclass index %u in class file %s",

grep -nr 'Invalid superclass index' *

hotspot/src/share/vm/classfile/classFileParser.cpp:3095: "Invalid superclass index %u in class file %s",

hotspot/src/share/vm/classfile/classFileParser.cpp:3100: "Invalid superclass index %u in class file %s",

Открываем classFileParser.cpp и там на 3095 строчке:

instanceKlassHandle ClassFileParser::parse_super_class(int super_class_index,
                                                       TRAPS) {
  instanceKlassHandle super_klass;
  if (super_class_index == 0) {
    check_property(_class_name == vmSymbols::java_lang_Object(),
                   "Invalid superclass index %u in class file %s",
                   super_class_index,
                   CHECK_NULL);
  } else {
    check_property(valid_klass_reference_at(super_class_index),
                   "Invalid superclass index %u in class file %s",
                   super_class_index,
                   CHECK_NULL);
    // The class name should be legal because it is checked when parsing constant pool.
    // However, make sure it is not an array type.
    bool is_array = false;
    if (_cp->tag_at(super_class_index).is_klass()) {
      super_klass = instanceKlassHandle(THREAD, _cp->resolved_klass_at(super_class_index));
      if (_need_verify)
        is_array = super_klass->oop_is_array();
    } else if (_need_verify) {
      is_array = (_cp->unresolved_klass_at(super_class_index)->byte_at(0) == JVM_SIGNATURE_ARRAY);
    }
    if (_need_verify) {
      guarantee_property(!is_array,
                        "Bad superclass name in class file %s", CHECK_NULL);
    }
  }
  return super_klass;
}

instanceKlassHandle ClassFileParser::parse_super_class(int super_class_index,

TRAPS) {

instanceKlassHandle super_klass;

if (super_class_index == 0) {

check_property(_class_name == vmSymbols::java_lang_Object(),

"Invalid superclass index %u in class file %s",

super_class_index,

CHECK_NULL);

} else {

check_property(valid_klass_reference_at(super_class_index),

"Invalid superclass index %u in class file %s",

super_class_index,

CHECK_NULL);

// The class name should be legal because it is checked when parsing constant pool.

// However, make sure it is not an array type.

bool is_array = false;

if (_cp->tag_at(super_class_index).is_klass()) {

super_klass = instanceKlassHandle(THREAD, _cp->resolved_klass_at(super_class_index));

if (_need_verify)

is_array = super_klass->oop_is_array();

} else if (_need_verify) {

is_array = (_cp->unresolved_klass_at(super_class_index)->byte_at(0) == JVM_SIGNATURE_ARRAY);

}

if (_need_verify) {

guarantee_property(!is_array,

"Bad superclass name in class file %s", CHECK_NULL);

}

return super_klass;

}

Нас интересует вот эта часть:

if (super_class_index == 0) {
  check_property(_class_name == vmSymbols::java_lang_Object(),
                 "Invalid superclass index %u in class file %s",
                 super_class_index,
                 CHECK_NULL);
}

if (super_class_index == 0) {

check_property(_class_name == vmSymbols::java_lang_Object(),

"Invalid superclass index %u in class file %s",

super_class_index,

CHECK_NULL);

}

check_property лежит в заголовочном файле classFileParser.hpp и выглядит так:

inline void check_property(bool property, const char* msg, int index, TRAPS) {
  if (_need_verify) {
    guarantee_property(property, msg, index, CHECK);
  } else {
    assert_property(property, msg, index, CHECK);
  }
}

inline void check_property(bool property, const char* msg, int index, TRAPS) {

if (_need_verify) {

guarantee_property(property, msg, index, CHECK);

} else {

assert_property(property, msg, index, CHECK);

}

Я стал искать где выставляется _need_verify и за что отвечает. Оказалось в classFileParser.cpp есть вот такая строчка:

_need_verify = Verifier::should_verify_for(class_loader(), verify);

1	_need_verify = Verifier::should_verify_for(class_loader(), verify);

verify передается при вызове:

instanceKlassHandle ClassFileParser::parseClassFile(Symbol* name,
                                                    ClassLoaderData* loader_data,
                                                    Handle protection_domain,
                                                    KlassHandle host_klass,
                                                    GrowableArray<Handle>* cp_patches,
                                                    TempNewSymbol& parsed_name,
                                                    bool verify,
                                                    TRAPS)

instanceKlassHandle ClassFileParser::parseClassFile(Symbol* name,

ClassLoaderData* loader_data,

Handle protection_domain,

KlassHandle host_klass,

GrowableArray<Handle>* cp_patches,

TempNewSymbol& parsed_name,

bool verify,

TRAPS)

Этот метод вызывается во многих местах, но нас интересует в hotspot/src/share/vm/classfile/classLoader.cpp:

instanceKlassHandle result = parser.parseClassFile(h_name,
                                                   loader_data,
                                                   protection_domain,
                                                   parsed_name,
                                                   false,
                                                   CHECK_(h));

instanceKlassHandle result = parser.parseClassFile(h_name,

loader_data,

protection_domain,

parsed_name,

false,

CHECK_(h));

Как же устроен should_verify_for в hotspot/src/share/vm/classfile/verifier.cpp:

bool Verifier::should_verify_for(oop class_loader, bool should_verify_class) {
  return (class_loader == NULL || !should_verify_class) ?
    BytecodeVerificationLocal : BytecodeVerificationRemote;
}

bool Verifier::should_verify_for(oop class_loader, bool should_verify_class) {

return (class_loader == NULL || !should_verify_class) ?

BytecodeVerificationLocal : BytecodeVerificationRemote;

}

Так как в should_verify_class мы передаем false, смотрим BytecodeVerificationLocal в hotspot/src/share/vm/runtime/arguments.cpp:

// -Xverify
    } else if (match_option(option, "-Xverify", &tail)) {
      if (strcmp(tail, ":all") == 0 || strcmp(tail, "") == 0) {
        FLAG_SET_CMDLINE(bool, BytecodeVerificationLocal, true);
        FLAG_SET_CMDLINE(bool, BytecodeVerificationRemote, true);
      } else if (strcmp(tail, ":remote") == 0) {
        FLAG_SET_CMDLINE(bool, BytecodeVerificationLocal, false);
        FLAG_SET_CMDLINE(bool, BytecodeVerificationRemote, true);
      } else if (strcmp(tail, ":none") == 0) {
        FLAG_SET_CMDLINE(bool, BytecodeVerificationLocal, false);
        FLAG_SET_CMDLINE(bool, BytecodeVerificationRemote, false);
      } else if (is_bad_option(option, args->ignoreUnrecognized, "verification")) {
        return JNI_EINVAL;
      }
    // -Xdebug
    }

// -Xverify

} else if (match_option(option, "-Xverify", &tail)) {

if (strcmp(tail, ":all") == 0 || strcmp(tail, "") == 0) {

FLAG_SET_CMDLINE(bool, BytecodeVerificationLocal, true);

FLAG_SET_CMDLINE(bool, BytecodeVerificationRemote, true);

} else if (strcmp(tail, ":remote") == 0) {

FLAG_SET_CMDLINE(bool, BytecodeVerificationLocal, false);

FLAG_SET_CMDLINE(bool, BytecodeVerificationRemote, true);

} else if (strcmp(tail, ":none") == 0) {

FLAG_SET_CMDLINE(bool, BytecodeVerificationLocal, false);

FLAG_SET_CMDLINE(bool, BytecodeVerificationRemote, false);

} else if (is_bad_option(option, args->ignoreUnrecognized, "verification")) {

return JNI_EINVAL;

}

// -Xdebug

}

Зарываясь дальше можно найти черную магию с макросами в hotspot/src/share/vm/runtime/globals_extension.hpp:

#define FLAG_SET_CMDLINE(type, name, value) (CommandLineFlagsEx::type##AtPut(FLAG_MEMBER_WITH_TYPE(name,type), (type)(value), Flag::COMMAND_LINE))

class CommandLineFlagsEx : CommandLineFlags {
 public:
  static void boolAtPut(CommandLineFlagWithType flag, bool value, Flag::Flags origin);
  static void intxAtPut(CommandLineFlagWithType flag, intx value, Flag::Flags origin);
  static void uintxAtPut(CommandLineFlagWithType flag, uintx value, Flag::Flags origin);
  static void uint64_tAtPut(CommandLineFlagWithType flag, uint64_t value, Flag::Flags origin);
  static void doubleAtPut(CommandLineFlagWithType flag, double value, Flag::Flags origin);
  static void ccstrAtPut(CommandLineFlagWithType flag, ccstr value, Flag::Flags origin);

  static bool is_default(CommandLineFlag flag);
  static bool is_ergo(CommandLineFlag flag);
  static bool is_cmdline(CommandLineFlag flag);
};

#define FLAG_SET_CMDLINE(type, name, value) (CommandLineFlagsEx::type##AtPut(FLAG_MEMBER_WITH_TYPE(name,type), (type)(value), Flag::COMMAND_LINE))

class CommandLineFlagsEx : CommandLineFlags {

public:

static void boolAtPut(CommandLineFlagWithType flag, bool value, Flag::Flags origin);

static void intxAtPut(CommandLineFlagWithType flag, intx value, Flag::Flags origin);

static void uintxAtPut(CommandLineFlagWithType flag, uintx value, Flag::Flags origin);

static void uint64_tAtPut(CommandLineFlagWithType flag, uint64_t value, Flag::Flags origin);

static void doubleAtPut(CommandLineFlagWithType flag, double value, Flag::Flags origin);

static void ccstrAtPut(CommandLineFlagWithType flag, ccstr value, Flag::Flags origin);

static bool is_default(CommandLineFlag flag);

static bool is_ergo(CommandLineFlag flag);

static bool is_cmdline(CommandLineFlag flag);

};

Но меня это пока не интересует. Мне надо выяснить значение BytecodeVerificationLocal, в случае когда jvm стартует без параметра -Xverify. Это можно найти в коде, но мне кажется, сейчас не уместным лезть дальнейшие дерби и пора выбираться. Документация в помощь. По дефолту jvm запускается с параметром -Xverify:remote и BytecodeVerificationLocal будет false.

Значит _need_verify тоже false и в check_property вызывается assert_property(property, msg, index, CHECK) с параметрами false, «Invalid superclass index %u in class file %s», 0, CHECK_NULL.

  inline void assert_property(bool b, const char* msg, int index, TRAPS) {
#ifdef ASSERT
    if (!b) {
      ResourceMark rm(THREAD);
      fatal(err_msg(msg, index, _class_name->as_C_string()));
    }
#endif
  }

inline void assert_property(bool b, const char* msg, int index, TRAPS) {

#ifdef ASSERT

if (!b) {

ResourceMark rm(THREAD);

fatal(err_msg(msg, index, _class_name->as_C_string()));

}

#endif

}

Собственно, здесь и выбрасывается сообщение об ошибке. Теперь посмотрим на fatal(msg), чтобы узнать как это делается.
Хотя, на часть вопроса мы уже ответили. Нельзя сделать classfile в котором для поля super_class будет значение 0 и загружать его с помощью дефолтного ClassLoader.

Итак, fatal определенный в hotspot/src/share/vm/utilities/debug.hpp:

#define fatal(msg)                                                           \
do {                                                                         \
  report_fatal(__FILE__, __LINE__, msg);                                     \
  BREAKPOINT;                                                                \
} while (0)

#define fatal(msg) \

do { \

report_fatal(__FILE__, __LINE__, msg); \

BREAKPOINT; \

} while (0)

hotspot/src/share/vm/utilities/debug.cpp:

void report_fatal(const char* file, int line, const char* message)
{
  report_vm_error(file, line, "fatal error", message);
}

void report_vm_error(const char* file, int line, const char* error_msg,
                     const char* detail_msg)
{
  if (Debugging || error_is_suppressed(file, line)) return;
  Thread* const thread = ThreadLocalStorage::get_thread_slow();
  VMError err(thread, file, line, error_msg, detail_msg);
  err.report_and_die();
}

void report_fatal(const char* file, int line, const char* message)

{

report_vm_error(file, line, "fatal error", message);

}

void report_vm_error(const char* file, int line, const char* error_msg,

const char* detail_msg)

{

if (Debugging || error_is_suppressed(file, line)) return;

Thread* const thread = ThreadLocalStorage::get_thread_slow();

VMError err(thread, file, line, error_msg, detail_msg);

err.report_and_die();

}

Реализация report_and_die() в hotspot/src/share/vm/utilities/vmError.cpp нетривиальна, но из нее следует, что в Java мы уже не возвращаемся и выводим сообщение об ошибке из недр jvm. На этом я хочу переостановить исследование jvm и java.lang.Object.

Выводы

java.lang.Object особый класс, имеющий уникальный class file, в котором в качестве суперкласса не указан ни один класс. Создать такой же класс средствами языка Java нельзя, но также затруднительно, если вообще возможно, сделать это и манипуляциями с байтами class файла. Надеюсь у меня получилось передать часть восхищения, которое я испытывал исследуя исходники jvm. Призываю всех попробовать сделать то же самое.

Источник

Как я писал Android приложение

August 30, 2018 by delfin

Не думал, что захочется поделиться опытом по написанию моего первого функционального Android приложения. Когда начинал его писать, думал, что всё будет просто, ведь, блин, их уже то понаписано тьма! Однако мне пришлось спотыкаться на ровном месте, причём не раз!

Итак, сменил я зимой сего года место работы. На новом месте свой интернет, свои “злые” айтишники и подумалось, что негоже мне светить в траффике урл сайта где я новости читаю. Скажем так, не популярен он в нынешнем обществе. Соответственно, приложение в Android самый логичный выход. Там может быть мобильный интернет и никто ничего с работы не увидит.

Стартап за 2 дня

Опыта работы по написанию приложений для Android у меня не было. Вернее, ещё в 2011, помнится, пытался баловаться плагинчиком для Eclipse. Но много лет прошло. Плагинчик уже не модный, а модна Idea. Вот и пришлось тыкать в новые кнопки и в новых окошках (не люблю я Idea). Тут же можно добавить всякоразные там проблемы с Android API, инициализацией проекта в IDE и другой сопроводительной активностью.

Тем не менее, за два дня функционал был готов. Я мог загружать список всех новостей и просматривать отдельную из них. С меня потребовалось всего лишь дамп HTML с сайта и его парсинг. Google дал информацию как это всё организовать в приложении. Ну а новостной сайт позволял это своей архитектурой.

Немножко напильником

Само собой, нужно было слегка подпилять, что было сделано за два дня. Я особо не заморачивался с красивостью кода, тестами и прочими тормозами стартапа. Пришлось всунуть jsoup для парсинга HTML, когда сабстрингать стало уже больно. Повозился с картинками, чтобы их ширина выравнивалась под размер экрана. Вырезка ненужного HTML и рекламных ссылок. Плюс один юнит тест. Неделя ушла на всё это.

Всё работает, но нет

В итоге у меня есть приложение, которое работает в эмуляторе. И даже впихнул его себе в телефон. Но вылезла беда. Если в сети WiFi оно ещё работает более-менее, то в мобильной сети оно совсем отказывалось вменяемо работать. Вернее, могло грузить список новостей несколько минут и то, не было гарантии, что все прогрузится. Причем речь шла о нескольких киллобайтах текста. Начались наблюдения. Оказалось, что у одного оператора тупит, у другого оператора почти не тупит. Примерно та же ситуация наблюдалась и при попытке зайти на сайт через браузер. 3G, 4G никакой роли не играли. На прямой вопрос у оператора: вы, уроды, сниффите? Ответ: нет конечно же! как вымогли подумать такое! Но факт есть факт. На все остальные сайты заходит вменяемо, но вот на мой, с новостями – тупит. Законная сторона меня лично не парит. Во первых, симка предоплатная, во-вторых закон я не нарушаю. Так что, стукачу оператору и рыцарям плаща и кинжала – физкульт привет! Парит меня, что работает никак моя аппликашка! Несколько месяцев я мучался, переключал симки в телефоне, но потом немножко разгрузился с текучкой и вернулся к разработке. Первым делом нужно было устранить сниффинг. Google плюс мой сайт с поддержкой PHP и проксик готов. Теперь контент грузится на обеих операторах одинаково, а на моём сайте заработал счётчик с посещениями. Ещё раз всем им там привет!

Грузи, грузи

За время, которое прошло, у меня на машине появился Docker. И это чудо не захотело дружить ни с VirtualBox, ни с Android эмулятором. Времени, а главное желания разбираться, в этом гауне не было. Пришлось разработку перенести на другую машину, попутно укрепив ненависть к Docker.

Чем парсишь, Вань

Всё. Новости вроде грузит нормально теперь, но вот если открываешь отдельно взятую – боль! Иногда грузит, но долго, иногда чёрный экран и ничего. Предположение первое – опять сеть. Дебаг мне в помощь и… Не сеть! Парсинг! Пришлось рефакторить парсер и мерять. Получив цифры для jsoup, я начал допиливать его конкурент на сабстрингах. И уже при частичной реализации парсинга я получил цифры 420 против 24. Я охренел – более чем на порядок отличие! Попытался поискать аналог jsoup, нашёл какой-то noname, но и его цифры (около 120) меня не соблазнили. Кроме того, у него был более тупой API чем у jsoup. Отсюда вынужденное решение – переписывать всё на сабстринги с последующей миграцией в StringBuilder. Уже чувствую вибрацию приверженцев секты “красивый код”, но мне, чёрт возьми, нужно было работающее приложение, а не красивый код внутри хреново рабочего! Много пришлось повозиться со всякими там циклами, скобочками и прочей мелочёвкой. Университет вспоминался часто с курсом основ алгоритмизации! Никаких новых алгоритмов! Упаси бог! Просто – необычные и запутанные циклы с индексами. Много циклов и индексов. Месяц ушёл на всё это.

Ща как запиздячу

Внутренне удовлетворение достигнуто. Но чхать моё приложение хотело на моё удовлетворение. Один хрен криво работало. Иногда новость подгружается весело и задорно, иногда тьма на весь экран, но с большой вероятностью подгрузки. Такое ощущение что ресурс у операционки занят и мой запрос на сервер что-то ждёт где-то в дебрях Android. Воркэраунд для этого вроде очевидный – запилить пул тредов и в фоне загружать новости в кеш, пока я читаю первую новость или просматриваю список новостей. Здесь было две попытки. Первая привела к стохастическому свалу всего приложения без объяснения причин. После того, как обернул код загрузки новости в try-catch-Throwable, проблема исчезла.

Итог

Через пол года у меня есть в телефоне приложение, которое:

Работает.
Меня не бесит.
Я его написал сам.
Есть куда по-чучуть что-то улучшать в будущем.

Мораль

Я не вспомнил о куче мелких “камушков” которые занимали время. Иконка, цвет кнопки, картика “под краешек” экрана и прочая мелочёвка. Хочу сказать, всё оно через Ж делается в Android. Такое вот втутреннее ощущение, что рудимент и рудиментом погоняет. Работа с Android помимо самой Java, требует ещё определённой сноровки и в самом фреймворке. Нельзя снисходительно джавистам отноститься к андройдщикам!

Много я не ожидал. Изначально думал, что всё будет гораздо проще. Например, я так и не докопал можно ли логировать работу приложения, трудности были с выплывающим окошком и т.д. Не ожидал, что будет столько проблем, не связанных с разработкой. По сути много затыков лежали в области внедрения и сопровождения приложения.

До сих пор остаётся открытым вопрос: написал бы я приложение, если бы уделял внимание всякоразным бестпрактисам, юнит тестам и TDD (шепотом и восхищённо)?

Также я бы подчеркнул, что разработка приложения это не есть непосредственно девелопмент с тестированием. Очень большую роль играет деливери и сопровождение. В моём случае, как видно, это были ключевые звенья в разработке. Никакими бестпрактисами я бы не отловил проблемы с мобильной сетью! Так что, как это может ни прискорбно для многих прозвучать, но будущее за “хуяк, хуяк и в продакшн”(c).

Включаем спринговые логи

February 7, 2018 by delfin

Spring как и любой другой сложный фреймворк умеет сам себя логировать. Иногда нужно уметь смотреть что там внутри происходит. Поэтому давайте попробуем разобраться, как можно заставить его говорить больше, чем он умеет по умолчанию.
Поставляется Spring со встроенным логгером JCL. По сути, это ранний аналог sf4j. Не сам логгер, а обёртка над различными имплементациями. Отсюда наша задача сводится к настройке JCL и стандартного Java логгера. Вполне, думаю, возможно подключить и другие реализации, но это всё зависит от конкретной задачи. Наша же заключается в том, чтобы Spring куда нибудь вывел дебажную информацию о себе. Поэтому Java логгера будет достаточно.
Итак. Задача сводится к следующим трём пунктам:
1) Нам нужно сказать JCL о том, чтобы он подключил Java логгер
2) Настроить Java логгер
3) Получить логи
Давайте теперь постараемся всё это реализовать:
1) Реализуется очень просто. Нужно всего лишь положить файл commons-logging.properties в корень нашего класспаса. Содержимое его должно быть:

org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger

1	org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger

Но, если копнуть глубже, и посмотреть внутрь JCL, то мы увидим, что это лишне, поскольку он сам по умолчанию использует Java логгер.
2) Создадим теперь файл для настроек Java логгера. Положите его в любое место и добавьте следующее содержимое:

# The following creates two handlers
handlers=java.util.logging.ConsoleHandler, java.util.logging.FileHandler

# Set the default logging level for the root logger
.level=SEVERE
# log level for the "com.rst.example" package
org.springframework.level=FINEST

# Set the default logging level
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.FileHandler.level=FINE

# Set the default formatter
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter

# Specify the location and name of the log file
java.util.logging.FileHandler.pattern=log-test.log

# The following creates two handlers

handlers=java.util.logging.ConsoleHandler, java.util.logging.FileHandler

# Set the default logging level for the root logger

.level=SEVERE

# log level for the "com.rst.example" package

org.springframework.level=FINEST

# Set the default logging level

java.util.logging.ConsoleHandler.level=ALL

java.util.logging.FileHandler.level=FINE

# Set the default formatter

java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter

java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter

# Specify the location and name of the log file

java.util.logging.FileHandler.pattern=log-test.log

Обратите внимание на строку 7. С её помощью можно получать логи из того пакета, который именно мы захотим.
3) Теперь чтобы это всё заработало нужно Java логгеру сказать, чтобы он настроился из того файла, который мы только что создали. Это можно сделать через системную переменную:

System.setProperty("java.util.logging.config.file","<path-to>java-logging.properties");

1	System.setProperty("java.util.logging.config.file","<path-to>java-logging.properties");

Обратите внимание, что здесь используется абсолютный путь к файлу.

Вот вроде и всё. С таким подходом можно получить логи любого фреймворка, который юзает JCL по умолчанию.

Полезная ссылка

Использование ThreadLocal переменных

December 14, 2017 by delfin

Введение

Вы уже наверно знаете, что поля классов в java бывают статические и не статические. Любое поле класса без модификатора static принадлежит объекту данного класса и создается каждый раз когда создается новый экземпляр класса. Статические переменные(помеченные модификатором static) не принадлежат экземпляру класса и существует всегда в единственном экземпляре независимо от того, сколько экземпляров класса было создано. Появившийся в java 1.2 класс java.lang.ThreadLocal по сути предоставляет нам ещё одну область жизни объектов, ThreadLocal предоставляет абстракцию над переменными локальными по отношению к потоку испольнения java.lang.Thread. ThreadLocal переменные отличаются от обычных переменных тем, что у каждого потока свой собственный, индивидуально инициализируемый экземпляр переменной, доступ к которой он получает через методы get() или set().

Я в своей практике встречался с четырьмя основными целями применения ThreadLocal переменных:
1. Упрощение API.
2. Cинтаксический сахар.
3. Кеширование непотокобезопасных(non thread safe) ресурсов.
4. Уменьшение области конкуренции между потоками(lock striping).

Упрощение API с помощью ThreadLocal.

Допустим Вы разрабатываете JEE веб приложение, после прохождения аутентификации на странице логина информация о пользователе запоминается в http сессии, и Вам в любой точке кода может понадобится информация о пользователе от которого пришел http запрос.
Наверняка Вы не захотите всю логику помещать в сервлеты и JSP, Вы выделети в приложение несколько слоев(бизнесс логика, доступ к данным и.т.д.), но после распределния ответсвенности по слоям у Вас может возникнуть проблема с тем, что не в каждой точке кода будет доступ к Http сессии, соответсвенно не везде можно будет узнать от какого пользователя пришел запрос.
Встает вопрос? а как проектировать свой API? Добавлять в каждый метод каждого класса дополнительный параметр представляющий данные пользователе?

До появления ThreadLocal это был единственный выход, с появлением же ThreadLocal мы можем привязать данные о пользователи к потоку обработки http запроса, и достать эту информацию в любом месте программы. Для этого нам понадобится зарегистрировать слушателя в контексте веб приложения который будет срабатывать на любой входящий http запрос:

Итак начнем с класса для реализации потокобезопсного контеста пользователя:

package ru.javatalks;

/**
 * @author Vermut
 *
 */
public class SecurityContextHolder {
	
	private static final ThreadLocal threadLocalScope = new  ThreadLocal<>();
	
	public final static User getLoggedUser() {
		return threadLocalScope.get();
	}
	
	public final static void setLoggedUser(User user) {
		threadLocalScope.set(user);
	}

}

package ru.javatalks;

/**

* @author Vermut

public class SecurityContextHolder {

private static final ThreadLocal threadLocalScope = new ThreadLocal<>();

public final static User getLoggedUser() {

return threadLocalScope.get();

}

public final static void setLoggedUser(User user) {

threadLocalScope.set(user);

}

Как мы знаем сервера приложений могут выполнять тысячи запросов одновременно и на первый взгляд такой код не потоко безопасен. Ведь действительно мы запоминаем текущего пользователя в статической переменной, а статическая переменная одна на весь класс, и вроде бы как паралельные http запросы должны перетирать данные друг друга.
Но вся фишка ThreadLocal заключается в том что имея всего одну ThreadLocal переменную, мы можем иметь различное значение для каждого из потоков, то есть один поток никогда не прочтет, удалит или не перезатрет данные присвоенные другим потоком. Таким образом несмотря на разделяемую статическую переменную код выше потоко-безопасен.Хранилище аутентификацционных данных написано, теперь нужно написать и сконфигурировать в web.xml слушателя входящих HTTP запросов, который бы при поступлении запроса присоеденяя данные о пользователе к потоку обработки а по завершении обработки запроса, очищал бы эту информацию.

package ru.javatalks;

import javax.servlet.ServletRequestEvent;
import javax.servlet.ServletRequestListener;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

/**
 * @author Vermut
 *
 */
public class AuthentificationPropagationListener implements ServletRequestListener {

	@Override
	public void requestInitialized(ServletRequestEvent event) {
		HttpServletRequest request = (HttpServletRequest) event.getServletRequest();
		HttpSession session = request.getSession(false);
		if (session == null) {
			return;
		}
		User user = (User) session.getAttribute("loged_user");
		SecurityContextHolder.setLoggedUser(user);
	}
	
	@Override
	public void requestDestroyed(ServletRequestEvent event) {
		SecurityContextHolder.setLoggedUser(null);
	}

}

package ru.javatalks;

import javax.servlet.ServletRequestEvent;

import javax.servlet.ServletRequestListener;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;

/**

* @author Vermut

public class AuthentificationPropagationListener implements ServletRequestListener {

@Override

public void requestInitialized(ServletRequestEvent event) {

HttpServletRequest request = (HttpServletRequest) event.getServletRequest();

HttpSession session = request.getSession(false);

if (session == null) {

return;

}

User user = (User) session.getAttribute("loged_user");

SecurityContextHolder.setLoggedUser(user);

}

@Override

public void requestDestroyed(ServletRequestEvent event) {

SecurityContextHolder.setLoggedUser(null);

}

Дело осталось за малым воспользоваться написаными функционалом из любой точки приложения в которой нет доста к http запросу или сессии:

package ru.javatalks;

/**
 * @author Vermut
 *
 */
public class OrderService {
	
	public void createOrder(Order order) {
		User user = SecurityContextHolder.getLoggedUser();
		checkEligibility(user, order.getSum());
		order.setUserId(user.getId())
		...
	}

}

package ru.javatalks;

/**

* @author Vermut

public class OrderService {

public void createOrder(Order order) {

User user = SecurityContextHolder.getLoggedUser();

checkEligibility(user, order.getSum());

order.setUserId(user.getId())

...

}

Конечно же функционал реализованный выше редко когда придется писать самому, есть множество библиотек связанных с security в которых это уже реализовано, например spring-security, стоит только иметь в виду что все они будут точно также работать посредством ThreadLocal. Построение API вокруг ThreadLocal широко используется в java enterprise edition и используется не только для ассоциирования контекста безопасности с потоком, но и для других вещей как например транзакции, открытые JPA сессии. Так же хочу заметить что использование ThreadLocal в JEE окружении сопряжено с возникновением многих проблемам и без глубокого понимания платформы jee, многопоточности и механизма загрузки классов от использования ThreadLocal в JEE лучше отказаться. Проблемы порождаемые ThreadLocal переменными в JEE окружении описаны в конце статьи.

2. Cинтаксический сахар или программирование на языке.

ThreadLocal можно использовть для добавления синтаксического сахара в язык java и многие библиотеки этим пользуются, например mybatis:

private String selectPersonSql() { 
    BEGIN(); // Clears ThreadLocal variable 
    SELECT("P.ID, P.USERNAME, P.PASSWORD, P.FULL_NAME"); 
    SELECT("P.LAST_NAME, P.CREATED_ON, P.UPDATED_ON"); 
    FROM("PERSON P"); 
    FROM("ACCOUNT A"); 
    INNER_JOIN("DEPARTMENT D on D.ID = P.DEPARTMENT_ID"); 
    INNER_JOIN("COMPANY C on D.COMPANY_ID = C.ID"); 
    WHERE("P.ID = A.ID"); 
    WHERE("P.FIRST_NAME like ?"); 
    OR(); 
    WHERE("P.LAST_NAME like ?"); 
    GROUP_BY("P.ID"); 
    HAVING("P.LAST_NAME like ?"); 
    OR(); 
    HAVING("P.FIRST_NAME like ?"); 
    ORDER_BY("P.ID"); 
    ORDER_BY("P.FULL_NAME"); 
    return SQL(); 
  }

private String selectPersonSql() {

BEGIN(); // Clears ThreadLocal variable

SELECT("P.ID, P.USERNAME, P.PASSWORD, P.FULL_NAME");

SELECT("P.LAST_NAME, P.CREATED_ON, P.UPDATED_ON");

FROM("PERSON P");

FROM("ACCOUNT A");

INNER_JOIN("DEPARTMENT D on D.ID = P.DEPARTMENT_ID");

INNER_JOIN("COMPANY C on D.COMPANY_ID = C.ID");

WHERE("P.ID = A.ID");

WHERE("P.FIRST_NAME like ?");

OR();

WHERE("P.LAST_NAME like ?");

GROUP_BY("P.ID");

HAVING("P.LAST_NAME like ?");

OR();

HAVING("P.FIRST_NAME like ?");

ORDER_BY("P.ID");

ORDER_BY("P.FULL_NAME");

return SQL();

}

Код получился легко читаемым, как видно функции BEGIN, SELECT и.т.д. не вызываются ни на одном объекте, то есть они статические и за счет статического импорта появившегося в java 5, вызов таких функций можно осуществлять без префикса класса. Потоко-безопасность достигается за счет того что каждый поток выполнения имеет собственный экземпляр билдера запросов. Конечно следует ожидать, что c появлением лямбд в java 8, использование ThreadLocal в качестве синтаксического сахара потеряет свою актуальность

Кеширование непотокобезопасных(non thread safe) ресурсов.

Однажды делая код ревью одного класса я обнаружил очень интересный баг многопоточности:

public class DateAdapter extends XmlAdapter<String, Date> {

    private static final DateFormat format = new SimpleDateFormat("dd.MM.yyyy");

    @Override
    public String marshal(Date value) throws Exception {
        return format.format(value);
    }

    @Override
    public Date unmarshal(String value) throws Exception {
        return isNullOrEmpty(value)? null: format.parse(value);  
    }

}

public class DateAdapter extends XmlAdapter<String, Date> {

private static final DateFormat format = new SimpleDateFormat("dd.MM.yyyy");

@Override

public String marshal(Date value) throws Exception {

return format.format(value);

}

@Override

public Date unmarshal(String value) throws Exception {

return isNullOrEmpty(value)? null: format.parse(value);

}

Класс использовался как кастомный адаптер для даты в JAXB. Вроде бы простой маленьки класс и в нём негде ошибится, однако есть одно но, класс java.text.SimpleDateFormat не является потоко безопасным, параллельные потоки должны либо синхронизировать доступ к инстансу объекта данного класса, либо отказаться от разделения одного инстанса SimpleDateFormat.
То есть просто создать один экземпляр формата и запомнить в статической переменной нельзя, иначе мы получим мусор на выходе если форматировать даты паралельно из нескольких потоков. Честно говоря в приложении рассчитаном на входящий поток данных 5 тысяч входящих документов в секунду, ни генерировать мусор создавая каждый раз новый экземпляр формата, ни тем более создавать бутылочное горлышко в виде synchronized блоков мне не хотелось, и поскольку стояло жесткое требование по максимуму отказаться от библиотек не входящих в j2se, то есть нельзя было использовать сторонние реализации форматеров то код выше превратился в следующее:

/**
 *
 * @author Vermut
 *
 */
public final class DateAdapter extends XmlAdapter<String, Date> {

    private static final ThreadLocal THREAD_CACHE = new ThreadLocal ();

    @Override
    public String marshal(Date value) throws Exception {
        return getFormat().format(value);
    }

    @Override
    public Date unmarshal(String value) throws Exception {
        return isNullOrEmpty(value)? null: getFormat().parse(value);
    }

    private static DateFormat getFormat() {
        DateFormat format = THREAD_CACHE.get();
        if (format == null) {
            format = new SimpleDateFormat("dd.MM.yyyy");
            THREAD_CACHE.set(format);
        }
        return format;
    }

}

/**

* @author Vermut

public final class DateAdapter extends XmlAdapter<String, Date> {

private static final ThreadLocal THREAD_CACHE = new ThreadLocal ();

@Override

public String marshal(Date value) throws Exception {

return getFormat().format(value);

}

@Override

public Date unmarshal(String value) throws Exception {

return isNullOrEmpty(value)? null: getFormat().parse(value);

}

private static DateFormat getFormat() {

DateFormat format = THREAD_CACHE.get();

if (format == null) {

format = new SimpleDateFormat("dd.MM.yyyy");

THREAD_CACHE.set(format);

}

return format;

}

Как видно обеспечено кеширование объектов DateFormat без синхронизации. В статье Java Best Practices – DateFormat in a Multithreading Environmentприведены результаты бенчмарков показывающих что такой подход позволяет увеличить производительность парсинга дат до 8 раз по сравнению с созданием каждый раз нового экземпляра формата.

Сужение области конкуренции между потоками(lock striping).

Lock striping техника представления сложного объекта, к которому осуществляется конкуретный доступ в виде отдельных маленьких частей, каждую часть такого объекта можно менять без блокировки целого объекта. Например техника lock striping применена в CuncurrentHashMap – вся коллекция разбита на регионы, и треды при модификации не конкурируют за всю коллекцию целиком, они конкурируют за её отдельные регионы, таким образом острота конкуренции снижается.

Прежде всего для этого параграфа хотелось бы сразу поместить disclaimer и cсылку на эту презентацию
, в презентации авторитетные специалисты в области java оптимизации в квалификации которых не возникает ни каких сомнений, крайне не рекомендуют использовать ThreadLocal для сuncurrent оптимизаций.

Однако пока java8 ещё не зарелизена, а в продакшн энтерпрайз приложений java8 попадет вообще не скоро, то пример использования ThreadLocal я всё же опубликую.

И так представим высоконагруженное приложение с тысячами рабочих потоков. Потоки занимаются тем что обрабатывают пачки входящих документов и нам бы хотелось собирать некоторую статистику о работе приложения, а конкретно количество обработанных документов. Но при этом мы бы хотели чтобы сбор статистики обходился нам бесплатно, и не вносил бы лишних нагрузку в приложение.
Какие сть варианты решения:
Выполнять запрос SELECT COUNT(*) FROM TABLE в базу данных – на таких объемах не очень удачное решение.
Заводить AtomicLong – поможет на небольшом количестве потоков, но не на тысячах.

Итак применим ThreadLocal. Общее количество обработанных сервером документов можно представить как сумму обработанных документов каждым рабочим потоком. То есть к каждому треду можно поставить соответсвии число, и он будет увеличивать это число вообще без конкуренции с каким либо другим потоком, то есть как мы и хотели сбор статистики обходится нам бесплатно.

package ru.javatalks;

import java.util.ArrayList;
import java.util.List;

/**
 * @author Vermut
 *
 */
package ru.javatalks;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.locks.ReentrantReadWriteLock;

/**
 * @author Vermut
 *
 */
public final class ThreadLocalAdder {
	
	private final ThreadLocal threadLocalScope = new ThreadLocal<>();
	private final List allThreadSums = new ArrayList<>();
	private final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
	
	public void add(long value) {
		SumContainer threadLocalSum = threadLocalScope.get();
		if (threadLocalSum == null) {
			threadLocalSum = new SumContainer();
			threadLocalScope.set(threadLocalSum);
			/*
			 * Самое первое получение локального блокирует подсчет общей суммы,
			 * но это критично только пока приложение не войдет в рабочий ритм, 
                         * в разогнавшемся приложении уже каждый поток хоть раз да проинкрементил свой счетчик.
			 */
			readWriteLock.writeLock().lock();
			try {
				allThreadSums.add(threadLocalSum);
			} finally {
				readWriteLock.writeLock().unlock();
			}
		}
		threadLocalSum.value += value;
	}
	
	public long getSum() {
		long sum = 0L;
		/*
		 * Как видно подсчет суммы медленная операция, так как сумма не хранится в готовом для чтения виде,
		 * что в принципе вписывается в концепцию lock striping, и не является критичным моментом в данном конкретном случае,
		 * так как админы приложения могут и несколько дней не заглядывать в перфоманс монитор.
		 */ 
		readWriteLock.readLock().lock();
		try {
			for (SumContainer threadLocalSum : allThreadSums) {
				sum += threadLocalSum.value;
			}
		} finally {
			readWriteLock.readLock().unlock();
		}
		return sum;
	}
	
	private static class SumContainer {
		/*
		 * Поле специально не volatile и не атомик, потому что абсолютная точность не нужна,
		 * допустимо чтобы запрос на получение статиcтики не увидел последних инкрементов сделанных рабочим потоком.
		 * Таким образом мы добились чего хотели, сбор статистики сделан бесплатным, его стоимость равна чтению из
		 * обычного (несинхронизированного) хешмапа коим по сути является ThreadLocal
		 */
		public long value;
		
	}

}

package ru.javatalks;

import java.util.ArrayList;

import java.util.List;

/**

* @author Vermut

package ru.javatalks;

import java.util.ArrayList;

import java.util.List;

import java.util.concurrent.locks.ReentrantReadWriteLock;

/**

* @author Vermut

public final class ThreadLocalAdder {

private final ThreadLocal threadLocalScope = new ThreadLocal<>();

private final List allThreadSums = new ArrayList<>();

private final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();

public void add(long value) {

SumContainer threadLocalSum = threadLocalScope.get();

if (threadLocalSum == null) {

threadLocalSum = new SumContainer();

threadLocalScope.set(threadLocalSum);

* Самое первое получение локального блокирует подсчет общей суммы,

* но это критично только пока приложение не войдет в рабочий ритм,

* в разогнавшемся приложении уже каждый поток хоть раз да проинкрементил свой счетчик.

readWriteLock.writeLock().lock();

try {

allThreadSums.add(threadLocalSum);

} finally {

readWriteLock.writeLock().unlock();

}

threadLocalSum.value += value;

}

public long getSum() {

long sum = 0L;

* Как видно подсчет суммы медленная операция, так как сумма не хранится в готовом для чтения виде,

* что в принципе вписывается в концепцию lock striping, и не является критичным моментом в данном конкретном случае,

* так как админы приложения могут и несколько дней не заглядывать в перфоманс монитор.

readWriteLock.readLock().lock();

try {

for (SumContainer threadLocalSum : allThreadSums) {

sum += threadLocalSum.value;

}

} finally {

readWriteLock.readLock().unlock();

}

return sum;

}

private static class SumContainer {

* Поле специально не volatile и не атомик, потому что абсолютная точность не нужна,

* допустимо чтобы запрос на получение статиcтики не увидел последних инкрементов сделанных рабочим потоком.

* Таким образом мы добились чего хотели, сбор статистики сделан бесплатным, его стоимость равна чтению из

* обычного (несинхронизированного) хешмапа коим по сути является ThreadLocal

public long value;

}

Для сокращения кода и упрощения понимания концепции ThreadLocal, из кода удалена обработка ситуаций внезапной смерти потоков. По хорошему нужно обрабатывать ситуацию, когда ThreadLocal собирается сборщиком мусора потому, что поток которому она принадлежит более недостижим из корня, но чтобы не отвлекать внимание читателя в сторону PhantomReference обработка этих ситуаций из кода удалена, а аспекты взаимодействия ThreadLocal и сборки мусора вынесены в отдельный параграф.А вот небольшой тест показывающий применение такого аккомулятора:

package ru.javatalks;

/**
 * @author Vermut
 *
 */
public class ThreadLocalAdderTest {
	
	private static final int OBSERVER_SLEEP_TIMEOUT = 1000;
	private static final long ITERATION_COUNT_PEER_THREAD = 1_000_000_000l;
	private static final int THREAD_COUNT = 10;
	private static final long INCREMENT_COUNT = 10;
	
	
	public static void main(String[] args) throws InterruptedException {
		ThreadLocalAdder threadLocalAdder = new ThreadLocalAdder();
		AdderThread[] threads = new AdderThread[THREAD_COUNT];
		for (int i = 0; i < THREAD_COUNT; i++) { threads[i] = new AdderThread(threadLocalAdder); threads[i].start(); } int aliveThreadCount = THREAD_COUNT; long previousSum = 0l; long sum = threadLocalAdder.getSum(); long sumNotChangedBeetweenIterationCount = 0l; long iterationCount = 0; while (aliveThreadCount > 0) {
			Thread.sleep(OBSERVER_SLEEP_TIMEOUT);
			iterationCount ++;
			aliveThreadCount = 0;
			for (AdderThread thread : threads) {
				if (thread.isAlive()) {
					aliveThreadCount ++;
				}
			}
			sum = threadLocalAdder.getSum();
			if (previousSum == sum) {
				sumNotChangedBeetweenIterationCount++;
			}
			System.out.println(iterationCount + " : " + sum + " : " +  sumNotChangedBeetweenIterationCount);
			previousSum = sum;
		}
		System.out.println(sum == ITERATION_COUNT_PEER_THREAD * THREAD_COUNT * INCREMENT_COUNT);
	}
	
	private static final class AdderThread extends Thread {
		
		private ThreadLocalAdder adder;

		public AdderThread(ThreadLocalAdder adder) {
			this.adder = adder;
		}
		
		@Override
		public void run() {
			for (long i = 0; i < ITERATION_COUNT_PEER_THREAD; i++) {
				adder.add(INCREMENT_COUNT);
			}
		}
	}

}

package ru.javatalks;

/**

* @author Vermut

public class ThreadLocalAdderTest {

private static final int OBSERVER_SLEEP_TIMEOUT = 1000;

private static final long ITERATION_COUNT_PEER_THREAD = 1_000_000_000l;

private static final int THREAD_COUNT = 10;

private static final long INCREMENT_COUNT = 10;

public static void main(String[] args) throws InterruptedException {

ThreadLocalAdder threadLocalAdder = new ThreadLocalAdder();

AdderThread[] threads = new AdderThread[THREAD_COUNT];

for (int i = 0; i < THREAD_COUNT; i++) { threads[i] = new AdderThread(threadLocalAdder); threads[i].start(); } int aliveThreadCount = THREAD_COUNT; long previousSum = 0l; long sum = threadLocalAdder.getSum(); long sumNotChangedBeetweenIterationCount = 0l; long iterationCount = 0; while (aliveThreadCount > 0) {

Thread.sleep(OBSERVER_SLEEP_TIMEOUT);

iterationCount ++;

aliveThreadCount = 0;

for (AdderThread thread : threads) {

if (thread.isAlive()) {

aliveThreadCount ++;

}

sum = threadLocalAdder.getSum();

if (previousSum == sum) {

sumNotChangedBeetweenIterationCount++;

}

System.out.println(iterationCount + " : " + sum + " : " + sumNotChangedBeetweenIterationCount);

previousSum = sum;

}

System.out.println(sum == ITERATION_COUNT_PEER_THREAD * THREAD_COUNT * INCREMENT_COUNT);

}

private static final class AdderThread extends Thread {

private ThreadLocalAdder adder;

public AdderThread(ThreadLocalAdder adder) {

this.adder = adder;

}

@Override

public void run() {

for (long i = 0; i < ITERATION_COUNT_PEER_THREAD; i++) {

adder.add(INCREMENT_COUNT);

}

Пять секретов… многопоточного Java-программирования

December 12, 2017 by delfin

Немногие Java™-разработчики могут позволить себе игнорировать многопоточное программирование и поддерживающие его библиотеки платформы Java, но еще меньше тех, кто располагает временем для глубинного изучения потоков. Вместо этого мы изучаем их спонтанно, добавляя в свой инструментарий новые рекомендации и приемы, когда нуждаемся в них. Это не лучший путь, хотя он и позволяет построить и запустить достойное приложение. Понимание потоковых механизмов компилятора Java и JVM поможет вам написать более эффективный, качественный и быстродействующий код Java.
В этой статье из цикла Пять секретов я расскажу о некоторых тонких аспектах многопоточного программирования с применением синхронизированных методов, volatile-переменных и атомарных классов. В частности, мы обсудим взаимодействие некоторых из этих конструкций с JVM и компилятором Java и влияние различных взаимодействий на производительность Java-приложения.

1. Синхронизированный метод или синхронизированный блок?

Развить навыки по этой теме
Этот материал — часть knowledge path для развития ваших навыков. Смотри Стать Java-программистом
Иногда приходится решать, синхронизировать ли вызов метода целиком или только потокобезопасное подмножество этого метода. В таких ситуациях полезно знать, что когда Java-компилятор преобразует исходный код в байт-код, он по-разному обрабатывает синхронизированные методы и синхронизированные блоки.
Когда JVM выполняет синхронизированный метод, исполняемый поток определяет, что в структуре method_info этого метода установлен флаг ACC_SYNCHRONIZED, а затем автоматически блокирует объект, вызывает метод и разблокирует объект. В случае исключительной ситуации поток автоматически снимает блокировку.
При синхронизации же блока кода метода встроенная в JVM поддержка блокировки объекта и обработки исключений не используется, и эта функциональность должна быть явно прописана в байт-коде. Если вы прочтете байт-код метода с синхронизированным блоком, то увидите более десятка дополнительных операций для управления этой функциональностью. В листинге 1 показаны вызовы для создания синхронизированного метода и синхронизированного блока.
Листинг 1. Два подхода к синхронизации

package com.geekcap;
 
public class SynchronizationExample {
    private int i;
 
    public synchronized int synchronizedMethodGet() {
        return i;
    }
 
    public int synchronizedBlockGet() {
        synchronized( this ) {
            return i;
        }
    }
}

package com.geekcap;

public class SynchronizationExample {

private int i;

public synchronized int synchronizedMethodGet() {

return i;

}

public int synchronizedBlockGet() {

synchronized( this ) {

return i;

}

Метод synchronizedMethodGet() генерирует следующий байт-код:

0:  aload_0
1:  getfield
2:  nop
3:  iconst_m1
4:  ireturn

0: aload_0

1: getfield

2: nop

3: iconst_m1

4: ireturn

А вот байт-код метода synchronizedBlockGet():

0:  aload_0
1:  dup
2:  astore_1
3:  monitorenter
4:  aload_0
5:  getfield
6:  nop
7:  iconst_m1
8:  aload_1
9:  monitorexit
10: ireturn
11: astore_2
12: aload_1
13: monitorexit
14: aload_2
15: athrow

0: aload_0

1: dup

2: astore_1

3: monitorenter

4: aload_0

5: getfield

6: nop

7: iconst_m1

8: aload_1

9: monitorexit

10: ireturn

11: astore_2

12: aload_1

13: monitorexit

14: aload_2

15: athrow

Для создания синхронизированного блока понадобилось 16 строк байт-кода, тогда как для синхронизации метода достаточно пяти.

2. Переменные ThreadLocal

Когда нужно сохранить один экземпляр переменной для всех экземпляров класса, используются переменные-члены статического класса. Когда же нужно сохранить по экземпляру переменной для каждого потока, следует использовать локальные переменные потока. Переменные ThreadLocal отличаются от обычных переменных тем, что в каждом потоке есть свой собственный индивидуально инициализированный экземпляр переменной, к которому он обращается посредством методов get() или set().
Допустим, вы разрабатываете многопоточный трассировщик кода, цель которого ― уникально идентифицировать путь каждого потока в вашем коде. Задача в том, чтобы скоординировать несколько методов из нескольких классов между несколькими потоками. Без ThreadLocal это было бы трудно сделать. Пришлось бы в начале исполнения потока создавать уникальный маркер для его идентификации в трассировщике, а затем передавать этот маркер каждому методу, встречающемуся по пути.
ThreadLocal все упрощает. В начале исполнения поток инициализирует локальную переменную потока, а затем обращается к ней из каждого метода в каждом классе с уверенностью, что переменная содержит сведения о трассировке только для текущего исполняемого потока. После исполнения поток может передать сведения о своем пути объекту управления, отвечающему за хранение всех путей.
Использование ThreadLocal имеет смысл, когда нужно хранить экземпляры переменных для каждого потока.

3. Volatile-переменные

По моей оценке, примерно половине всех Java-разработчиков известно о наличии в языке Java ключевого слова volatile. Из них лишь около 10% знают, что оно означает, и еще меньше ― как его эффективно использовать. Вкратце, определение переменной с ключевым словом volatile означает, что значение этой переменной может изменяться другими потоками. Чтобы как следует понять, что делает ключевое слово volatile, полезно разобраться, как потоки обрабатывают обычные переменные.
В целях повышения производительности спецификация языка Java допускает сохранение в JRE локальной копии переменной для каждого потока, который на нее ссылается. Такие «локальные» копии переменных напоминают кэш и помогают потоку избежать обращения к главной памяти каждый раз, когда требуется получить значение переменной.
Но давайте посмотрим, что происходит в следующем сценарии: запускаются два потока, и один из них считывает переменную A как 5, а второй ― как 10. Если значение переменной А изменилось с 5 на 10, то первый поток не узнает об изменении и будет хранить неправильное значение A. Однако если переменная А помечена как volatile, то когда бы поток не считывал значение A, он будет обращаться к главной копии A и считывать ее текущее значение.
Локальный кэш потока имеет смысл в том случае, если переменные в ваших приложениях не будут изменяться извне. Если это не так, то знать, что делает ключевое слово volatile, очень полезно.

4. Volatile- или синхронизированные переменные?

Если переменная объявлена как volatile, это означает, что она может изменяться разными потоками. Естественно ожидать, что JRE обеспечит ту или иную форму синхронизации таких volatile-переменных. JRE действительно неявно обеспечивает синхронизацию при доступе к volatile-переменным, но с одной очень большой оговоркой: чтение volatile-переменной и запись в volatile-переменную синхронизированы, а неатомарные операции ― нет.
Это означает, что следующий код не является потокобезопасным:

myVolatileVar++;

1	myVolatileVar++;

Предыдущий оператор можно записать и так:

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

int temp = 0;

synchronize( myVolatileVar ) {

temp = myVolatileVar;

}

temp++;

synchronize( myVolatileVar ) {

myVolatileVar = temp;

}

Другими словами, если volatile-переменная обновляется таким образом, что ее значение считывается, изменяется, и ей “под капотом” присваивается новое значение, то результатом будет непотокобезопасная операция, выполняемая между двумя синхронными операциями. Остается решить, использовать ли явную синхронизацию или же полагаться на поддержку автоматической синхронизации volatile-переменных в JRE. Наилучший подход зависит от обстоятельств: если новое значение volatile-переменной зависит от ее текущего значения (как при операции инкремента), то нужна явная синхронизация, чтобы эта операция была потокобезопасной.

5. Атомарные корректоры полей

При увеличении или уменьшении значения примитива в многопоточной среде гораздо выгоднее использовать один из новых атомарных классов из пакета java.util.concurrent.atomic, чем писать свой собственный синхронизированный блок кода. Атомарные классы гарантируют выполнение определенных операций, таких как увеличение и уменьшение, обновление или добавление значения, потокобезопасным способом. В перечень атомарных классов входят классы AtomicInteger, AtomicBoolean, AtomicLong, AtomicIntegerArray и т.п.
Проблема использования атомарных классов состоит в том, что все операции класса, включая get, set и семейство операций get-set, оказываются атомарными. Это означает, что операции read и write, которые не изменяют значения атомарной переменной, ― это не просто важные, а синхронизированные операции read-update-write. Если требуется более детальное управление развертыванием синхронизированного кода, то обходной путь заключается в использовании атомарного корректора полей.
Использование атомарных обновлений
Атомарные корректоры полей, такие как AtomicIntegerFieldUpdater, AtomicLongFieldUpdater и AtomicReferenceFieldUpdater, по сути, представляют собой оболочку volatile-поля. Они используются внутри библиотек Java-классов. Эти корректоры не нашли широкого применения в коде приложений, но избегать их нет никаких причин.
В листинге 2 приведен пример класса, использующего атомарные корректоры для изменения названия книги, которую кто-то читает.
Листинг 2. Класс Book

package com.geeckap.atomicexample;
 
public class Book
{
    private String name;
 
    public Book()
    {
    }
 
    public Book( String name )
    {
        this.name = name;
    }
 
    public String getName()
    {
        return name;
    }
 
    public void setName( String name )
    {
        this.name = name;
    }
}

package com.geeckap.atomicexample;

public class Book

{

private String name;

public Book()

{

}

public Book( String name )

{

this.name = name;

}

public String getName()

{

return name;

}

public void setName( String name )

{

this.name = name;

}

Класс Book – это простой объект Java (POJO) с единственным полем: name.
Листинг 3. Класса MyObject

package com.geeckap.atomicexample;
 
import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;
 
/**
 *
 * @author shaines
 */
public class MyObject
{
    private volatile Book whatImReading;
 
    private static final AtomicReferenceFieldUpdater<MyObject,Book> updater =
            AtomicReferenceFieldUpdater.newUpdater( 
                       MyObject.class, Book.class, "whatImReading" );
 
    public Book getWhatImReading()
    {
        return whatImReading;
    }
 
    public void setWhatImReading( Book whatImReading )
    {
        //this.whatImReading = whatImReading;
        updater.compareAndSet( this, this.whatImReading, whatImReading );
    }
}

package com.geeckap.atomicexample;

import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;

/**

* @author shaines

public class MyObject

{

private volatile Book whatImReading;

private static final AtomicReferenceFieldUpdater<MyObject,Book> updater =

AtomicReferenceFieldUpdater.newUpdater(

MyObject.class, Book.class, "whatImReading" );

public Book getWhatImReading()

{

return whatImReading;

}

public void setWhatImReading( Book whatImReading )

{

//this.whatImReading = whatImReading;

updater.compareAndSet( this, this.whatImReading, whatImReading );

}

Класс MyObject в листинге 3 предоставляет свое свойство whatAmIReading обычным образом, с помощью методов get и set, но метод set делает нечто особенное. Вместо того чтобы просто присвоить свою внутреннюю ссылку Book указанному объекту Book (что достигается с помощью кода, закомментированного в листинге 3), он использует AtomicReferenceFieldUpdater.

AtomicReferenceFieldUpdater

В Javadoc класс AtomicReferenceFieldUpdater определяется следующим образом:
Основанная на отражении (reflection-based) утилита, которая обеспечивает атомарное обновление указанных опорных volatile-полей указанных классов. Этот класс предназначен для использования в атомарных структурах данных, где несколько опорных полей одного и того же узла независимо подлежат атомарному обновлению.
В листинге 3 класс AtomicReferenceFieldUpdater создается с помощью вызова его статического метода newUpdater, принимающего три параметра:
класс объекта, содержащий поле (в данном случае, MyObject);
класс объекта, подлежащий атомарному обновлению (в данном случае, Book);
имя поля, подлежащего атомарному обновлению.
Реальная выгода здесь заключается в том, что метод getWhatImReading выполняется без всякой синхронизации, в то время как setWhatImReading выполняется как атомарная операция.
В листинге 4 показано, как использовать метод setWhatImReading() с гарантией правильного изменения значения.
Листинг 4. Пример атомарного обновления

package com.geeckap.atomicexample;
 
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
 
public class AtomicExampleTest
{
    private MyObject obj;
 
    @Before
    public void setUp()
    {
        obj = new MyObject();
        obj.setWhatImReading( new Book( "Java 2 From Scratch" ) );
    }
 
    @Test
    public void testUpdate()
    {
        obj.setWhatImReading( new Book( 
                "Pro Java EE 5 Performance Management and Optimization" ) );
        Assert.assertEquals( "Incorrect book name", 
                "Pro Java EE 5 Performance Management and Optimization", 
                obj.getWhatImReading().getName() );
    }
 
}

package com.geeckap.atomicexample;

import org.junit.Assert;

import org.junit.Before;

import org.junit.Test;

public class AtomicExampleTest

{

private MyObject obj;

@Before

public void setUp()

{

obj = new MyObject();

obj.setWhatImReading( new Book( "Java 2 From Scratch" ) );

}

@Test

public void testUpdate()

{

obj.setWhatImReading( new Book(

"Pro Java EE 5 Performance Management and Optimization" ) );

Assert.assertEquals( "Incorrect book name",

"Pro Java EE 5 Performance Management and Optimization",

obj.getWhatImReading().getName() );

}

Подробнее об атомарных классах см. в разделе Ресурсы.

Заключение

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

Ресурсы

Оригинал статьи: 5 things you didn’t know about … multithreaded Java programming.
Пять секретов…: цикл статей, содержащих полезные советы по Java-программированию.
Java Concurrency in Practice (Brian Goetz, et. al. Addison-Wesley, 2006): удивительная способность Брайана объяснять сложные концепции простым языком делает эту книгу необходимой в библиотеке любого Java-программиста.
Code Tracing (Steven Haines, InformIT, август 2010 г.): подробнее о трассировке кода с помощью переменных ThreadLocal.
Java bytecode: Understanding bytecode makes you a better programmer(Peter Haggar, developerWorks, июль 2001 г.): введение в малоизвестные области байткода, включая приведенный выше пример, иллюстрирующий разницу между синхронизированными методами и синхронизированными блоками.
Java theory and practice: Going atomic (Brian Goetz, developerWorks, ноябрь 2004 г.): о том, как атомарные классы позволяют разрабатывать высокомасштабируемые неблокирующие алгоритмы на языке Java.
Java theory and practice: Concurrency made simple (sort of) (Brian Goetz, developerWorks, ноябрь 2002 г.): экскурс в пакет java.util.concurrent.
5 things you didn’t know about … java.util.concurrent, Part 1 (Ted Neward, developerWorks, май 2010 г.): о пяти классах параллельных коллекций, которые модифицируют стандартные классы коллекций для нужд параллельного программирования.

Источник

Как работает ConcurrentHashMap

December 11, 2017 by delfin

В октябре на хабре появилась замечательная статья про работу HashMap. Продолжая данную тему, я собираюсь рассказать о реализации java.util.concurrent.ConcurrentHashMap.
Итак, как же появился ConcurrentHashMap, какие у него есть преимущества и как он был реализован.

Предпосылки к созданию ConcurrentHashMap

До появления в JDK 1.5 реализации ConcurrentHashMap, существовало несколько способов описания хэш-таблиц.
Первоначально в JDK 1.0 был клас Hashtable. Hashtable — потокобезопасная и легкая в использовании реализация хэш-таблицы. Проблема HashTable заключалась, в первую очередь, в том, что при доступе к элементам таблицы производилась её полная блокировка. Все методы Hashtable были синхронизированными. Это являлось серьёзным ограничением для многопоточной среды, поскольку плата за блокировку всей таблицы была очень большой.
В JDK 1.2 на помощь Hashtable пришёл HashMap и его потокобезопасное представление — Collections.synchronizedMap. Причин для такого разделения было несколько:

Не каждый программист и не каждое решение нуждались в использовании потокобезопасной хэш-таблицы
Программисту необходимо было дать выбор, какой вариант ему удобно использовать

Таким образом, c JDK 1.2 список вариантов реализации хэш-карт в Java пополнился ещё двумя способами. Однако эти способы не избавили разработчиков от появления в их коде race conditions, которые могли привести к появлению ConcurrentModificationException. В данной статье подробнее рассказано о возможных причинах их появления в коде.
И вот, в JDK 1.5 наконец появляется более производительный и масштабируемый вариант.

ConcurrentHashMap

К моменту появления ConcurrentHashMap Java-разработчики нуждались в следующей реализации хэш-карты:

Потокобезопасность
Отсутствие блокировок всей таблицы на время доступа к ней
Желательно, чтобы отсутствовали блокировки таблицы при выполнении операции чтения

Doug Lea представляет вариант реализации такой структуры данных, которая включается в JDK 1.5.
Какие же основные идеи реализации ConcurrentHashMap?

1. Элементы карты

В отличие от элементов HashMap, Entry в ConcurrentHashMap объявлены как volatile. Это важная особенность, также связанная с изменениями в JMM. Ответ Doug Lea о необходимости использования volatile и возможных race condition можно прочитать здесь.

static final class HashEntry<K, V> {
    final K key;
    final int hash;
    volatile V value;
    final HashEntry<K, V> next;

    HashEntry(K key, int hash, HashEntry<K, V> next, V value) {
        this .key = key;
        this .hash = hash;
        this .next = next;
        this .value = value;
     }

    @SuppressWarnings("unchecked")
    static final <K, V> HashEntry<K, V>[] newArray(int i) {
        return new HashEntry[i];
    }
}

static final class HashEntry<K, V> {

final K key;

final int hash;

volatile V value;

final HashEntry<K, V> next;

HashEntry(K key, int hash, HashEntry<K, V> next, V value) {

this .key = key;

this .hash = hash;

this .next = next;

this .value = value;

}

@SuppressWarnings("unchecked")

static final <K, V> HashEntry<K, V>[] newArray(int i) {

return new HashEntry[i];

}

2. Хэш-функция

В ConcurrentHashMap также используется улучшенная функция хэширования.
Напомню, какой она была в HashMap из JDK 1.2:

static int hash(int h) {
    h ^= (h >>> 20) ^ (h >>> 12);
    return h ^ (h >>> 7) ^ (h >>> 4);
}

static int hash(int h) {

h ^= (h >>> 20) ^ (h >>> 12);

return h ^ (h >>> 7) ^ (h >>> 4);

}

Версия из ConcurrentHashMap JDK 1.5:

private static int hash(int h) {
    h += (h << 15) ^ 0xffffcd7d;
    h ^= (h >>> 10);
    h += (h << 3);
    h ^= (h >>> 6);
    h += (h << 2) + (h << 14);
    return h ^ (h >>> 16);
}

private static int hash(int h) {

h += (h << 15) ^ 0xffffcd7d;

h ^= (h >>> 10);

h += (h << 3);

h ^= (h >>> 6);

h += (h << 2) + (h << 14);

return h ^ (h >>> 16);

}

В чём необходимость усложнения хэш-функции? Таблицы в хэш-карте имеют длину, определяемую степенью двойки. Для хэш-кодов, двоичные представления которых не различаются в младшей и старшей позиции, мы будем иметь коллизии. Усложнение хэш-функции как раз решает данную проблему, уменьшая вероятность коллизий в карте.

3. Сегменты

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

    final Segment<K, V>[] segments;
    transient Set<K> keySet;
    transient Set<Map.Entry<K, V>> entrySet;
    transient Collection<V> values;

final Segment<K, V>[] segments;

transient Set<K> keySet;

transient Set<Map.Entry<K, V>> entrySet;

transient Collection<V> values;

Рассмотрим, что же представляет из себя класс сегмента:

static final class Segment<K, V> extends ReentrantLock implements 
                    Serializable {
    private static final long serialVersionUID = 2249069246763182397L;
    transient volatile int count;
    transient int modCount;
    transient int threshold;
    transient volatile HashEntry<K, V>[] table;

     final float loadFactor;

    Segment(int initialCapacity, float lf) {
         loadFactor = lf;
         setTable(HashEntry.<K, V> newArray(initialCapacity));
     }

    ...
}

static final class Segment<K, V> extends ReentrantLock implements

Serializable {

private static final long serialVersionUID = 2249069246763182397L;

transient volatile int count;

transient int modCount;

transient int threshold;

transient volatile HashEntry<K, V>[] table;

final float loadFactor;

Segment(int initialCapacity, float lf) {

loadFactor = lf;

setTable(HashEntry.<K, V> newArray(initialCapacity));

}

...

}

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

4. ConcurrencyLevel

Данный параметр влияет на использование картой памяти и количество сегментов в карте.
Посмотрим на создание карты и на то, как влияет заданный в качестве парамента конструктора concurrencyLevel:

public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) {
     if (!(loadFactor > 0) || initialCapacity < 0
          || concurrencyLevel <= 0)
     throw new IllegalArgumentException();

     if (concurrencyLevel > MAX_SEGMENTS)
     concurrencyLevel = MAX_SEGMENTS;

     // Find power-of-two sizes best matching arguments
     int sshift = 0;
     int ssize = 1;
     while (ssize < concurrencyLevel) {
          ++sshift;
          ssize <<= 1;
     }
     segmentShift = 32 - sshift;
     segmentMask = ssize - 1;
     this .segments = Segment.newArray(ssize);

     if (initialCapacity > MAXIMUM_CAPACITY)
          initialCapacity = MAXIMUM_CAPACITY;
     int c = initialCapacity / ssize;
     if (c * ssize < initialCapacity)
          ++c;
     int cap = 1;
     while (cap < c)
          cap <<= 1;

     for (int i = 0; i < this .segments.length; ++i)
          this .segments[i] = new Segment<K, V>(cap, loadFactor);
}

public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) {

if (!(loadFactor > 0) || initialCapacity < 0

|| concurrencyLevel <= 0)

throw new IllegalArgumentException();

if (concurrencyLevel > MAX_SEGMENTS)

concurrencyLevel = MAX_SEGMENTS;

// Find power-of-two sizes best matching arguments

int sshift = 0;

int ssize = 1;

while (ssize < concurrencyLevel) {

++sshift;

ssize <<= 1;

}

segmentShift = 32 - sshift;

segmentMask = ssize - 1;

this .segments = Segment.newArray(ssize);

if (initialCapacity > MAXIMUM_CAPACITY)

initialCapacity = MAXIMUM_CAPACITY;

int c = initialCapacity / ssize;

if (c * ssize < initialCapacity)

++c;

int cap = 1;

while (cap < c)

cap <<= 1;

for (int i = 0; i < this .segments.length; ++i)

this .segments[i] = new Segment<K, V>(cap, loadFactor);

}

Количество сегментов будет выбрано как ближайшая степень двойки, большая чем concurrencyLevel. Ёмкость каждого сегмента, соответственно, будет определяться как отношение округлённого до ближайшей большей степени двойки значения ёмкости карты по умолчанию, к полученному количеству сегментов.
Очень важно понимать две следующие вещи. Занижение concurrencyLevel ведёт к тому, что более вероятны блокировки потоками сегментов карты при записи. Завышение показателя ведёт к неэффективному использованию памяти.

Как же выбрать concurrencyLevel?

Если лишь один поток будет изменять карту, а остальные будут производить чтение — рекомендуется использовать значение 1.
Необходимо помнить, что resize таблиц для хранения внутри карти — опреация, требующая дополнительного времени (и, зачастую, выполняемая не быстро). Поэтому при создании карты требуется иметь некоторые приблизительные оценки по статистике выполнения возможных операций чтения и записи.

Оценки масштабируемости

На javamex можно найти статью о сравнении масштабируемости synchronizedMap и ConcurrentHashMap:

Как видно из графика, между 5 и 10 миллионами операций доступа к карте заметно серьёзное расхождение, что обуславливает эффективность применения ConcurrentHashMap в случае с высоким количеством хранимых данных и операций доступа к ним.

Итого

Итак, основные преимущества и особенности реализации ConcurrentHashMap:

Карта имеет схожий с hashmap интерфейс взаимодействия
Операции чтения не требуют блокировок и выполняются параллельно
Операции записи зачастую также могут выполняться параллельно без блокировок
При создании указывается требуемый concurrencyLevel, определяемый по статистике чтения и записи
Элементы карты имеют значение value, объявленное как volatile

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

Полезные ресурсы по параллельным коллекциям в Java и, в частности, по работе ConcurrentHashMap:

Источник

Откуда растут ноги у hashCode

November 24, 2017 by delfin

Опять на собеседованиях по Java спрашивают про hashCode и equals? А кто из собеседующих сам ответит на вопрос, как вычисляется Object.hashCode() и System.identityHashCode()? Насколько дорог вызов этих методов? Как их можно ускорить в HotSpot JVM? Держу пари, едва ли кто даст правильный ответ. Разве что, кто прочитает эту статью.

Существует распространенное заблуждение, что Object.hashCode возвращает адрес объекта в памяти. Когда-то давно, наверное, так оно и было. Например, Dalvik VM до сих пор использует адрес объекта, сдвинутый на 3 бита вправо. Однако такая реализация неудачна: во-первых, последовательно выделяемые объекты будут иметь последовательные хеш-коды; во-вторых, сборщик мусора может передвигать объекты в памяти, меняя их адреса.

Так получилось, что на прошлой неделе я дважды столкнулся с темой вычисления хеш-кода, что и побудило меня написать заметку. Сначала попался на глаза крайне несправедливо заминусованный комментарий. Именно SSSurkv совершенно верно предположил, что для вычисления Object.hashCode используется генератор случайных чисел.
– Как так? – спросите вы. – Ведь хеш-код объекта должен оставаться постоянным в течение жизни приложения.

Все верно. Встроенный хеш-код генерируется лишь один раз для каждого объекта при первом вызове метода hashCode(), после чего сохраняется в заголовке объекта для последующих вызовов. Но для первого раза используется именно random! Убедитесь сами, заглянув в исходники OpenJDK (функция get_next_hash).

Вероятно, я бы забыл про этот случай, если бы на днях не столкнулся с реальной проблемой в реальном проекте. Профилируя приложение, среди горячих методов я неожиданно увидел IdentityHashMap.put(), который, на мой взгляд, реализован довольно эффективно. Узким местом оказался System.identityHashCode(), на который IdentityHashMap полагается. Причем медленным был только первый вызов identityHashCode на объекте. Второй и последующие вызовы, как мы теперь знаем, берут сохраненное значение из заголовка.

Но нет худа без добра. Дело в том, что в HotSpot можно выбирать реализацию Object.hashCode с помощью ключа командной строки -XX:hashCode=n (где n от 0 до 5).
0 – Park-Miller RNG (по умолчанию)
1 – f(адрес, глобальное_состояние)
2 – константа 1
3 – последовательный счетчик
4 – адрес объекта
5 – Thread-local Xorshift
Наиболее адекватным, на мой взгляд, является последний – он дает неплохое равномерное распределение, используя только битовые операции, и, что важно для конкурентных алгоритмов, не трогает глобальные переменные.
Так, всего лишь добавив ключ JVM -XX:hashCode=5, я магическим образом ускорил свой алгоритм на 30%! Почему этот вариант до сих пор не сделали дефолтным, остается загадкой…

Напоследок забавный факт: хотспотовский hashCode никогда не вернет 0, так как 0 считается признаком того, что хеш-код для данного объекта еще не генерировался:
if (value == 0) value = 0xBAD ;

Надеюсь, теперь, когда вы узнали всю правду о hashCode, вы сможете не только удивить коллег на собеседовании, но и сделать свои алгоритмы еще эффективнее.

Источник

Класс Object в Java

November 24, 2017 by delfin

Класс Object, из пакета java.lang, находится на вершине дерева иерархии классов. Каждый класс является потомком, прямым или косвенным, класса Object. Любой использованный или написанный нами класс наследует методы этого класса. Благодаря этому мы можем сослаться на объект, тип которого нам не известен.

Исходный код данного класса из OpenJDK можно посмотреть тут.

Разберемся по порядку с методами этого класса.

private static native void registerNatives();

1	private static native void registerNatives();

Обычно, для того, чтобы JVM нашла нативные функции, они должны быть названы определенным образом. Например для java.lang.Object.registerNatives, соответствующая функция на С должна называться Java_java_lang_Object_registerNatives. Используя JNI функцию registerNatives можно именовать наши С функции как захочется.

Код на С :

static JNINativeMethod methods[] = {
    {"hashCode",    "()I",                    (void *)&amp;JVM_IHashCode},
    {"wait",        "(J)V",                   (void *)&amp;JVM_MonitorWait},
    {"notify",      "()V",                    (void *)&amp;JVM_MonitorNotify},
    {"notifyAll",   "()V",                    (void *)&amp;JVM_MonitorNotifyAll},
    {"clone",       "()Ljava/lang/Object;",   (void *)&amp;JVM_Clone},
};

JNIEXPORT void JNICALL
Java_java_lang_Object_registerNatives(JNIEnv *env, jclass cls)
{
    (*env)-&gt;RegisterNatives(env, cls,
    methods, sizeof(methods)/sizeof(methods[0]));
}

static JNINativeMethod methods[] = {

{"hashCode", "()I", (void *)&JVM_IHashCode},

{"wait", "(J)V", (void *)&JVM_MonitorWait},

{"notify", "()V", (void *)&JVM_MonitorNotify},

{"notifyAll", "()V", (void *)&JVM_MonitorNotifyAll},

{"clone", "()Ljava/lang/Object;", (void *)&JVM_Clone},

};

JNIEXPORT void JNICALL

Java_java_lang_Object_registerNatives(JNIEnv *env, jclass cls)

{

(*env)->RegisterNatives(env, cls,

methods, sizeof(methods)/sizeof(methods[0]));

}

Следует заметить, что Object.getClass нет в этом списке. Это значит что он будет вызываться со стандартным именем Java_java_lang_Object_getClass.
Регистрация нативных функций также полезна если мы встраиваем Java в программу на С и хотим ссылаться на функции своего приложения, а не на функции из общей библиотеки или хотим привязать нативные методы к другим функциям на С.

Далее идет статичный конструктор.

static {
    registerNatives();
}

static {

registerNatives();

}

public final native Class<?> getClass();

1	public final native Class<?> getClass();

Этот метод нельзя переопределить.
Возвращает класс объекта, методы которого можно использовать для получения информации об этом классе, например его имя (getSimpleName()), его суперкласс (getSuperClass()), и реализуемых интерфейсах (getInterfaces()).
Например, следующий метод выведет имя класса объекта:

void printClassName(Object obj) {
    System.out.println("The object's" + " class is " + obj.getClass().getSimpleName());
}

void printClassName(Object obj) {

System.out.println("The object's" + " class is " + obj.getClass().getSimpleName());

}

public native int hashCode();

1	public native int hashCode();

Возвращает хэш-код объекта. Этот метод поддерживается в интересах хэш-таблиц (таких как HashMap, например).

По умолчанию, если два объекта равны, их хэш-коды должны быть также равны. Если переопределить метод equals(), реализация метода hashCode() у Object перестает быть корректной. Поэтому, если мы переопределяем метод equals(), мы должны переопределить метод hashCode().

В доках Oracle написано: нативный метод реализован так, что возвращает адрес объекта в памяти.
В openJDK 7 для HotSpot JVM он основан на генераторе случайных чисел. Смотреть метод get_next_hash.

Но также можно выбрать другой режим, в том числе и адрес в памяти.

С помощью ключа командной строки -XX:hashCode=n (где n от 0 до 5).
0 – Park-Miller RNG (по умолчанию)
1 – f(адрес, глобальное_состояние)
2 – константа 1
3 – последовательный счетчик
4 – адрес объекта
5 – Thread-local Xorshift

public boolean equals(Object obj) {
    return (this == obj);
}

public boolean equals(Object obj) {

return (this == obj);

}

Метод сравнивает два объекта и возвращает true, если они равны. Метод equals(), реализованный в классе Object использует тождественный оператор (==), чтобы определить, являются ли два объекта равными. Для примитивных типов данных это корректно. Для объектов метод проверяет только то, ссылки указывают на один и тот-же объект.
Всегда надо переопределять метод equals(), если сравнение тождественным оператором не подходит для объекта.
Переопределив метод equals() обязывает разработчика переопределить метод hashCode().

protected native Object clone() throws CloneNotSupportedException;

1	protected native Object clone() throws CloneNotSupportedException;

Если класс или один из его суперклассов реализуют интерфейс Cloneable, то можно использовать метод clone() для создания копии существующего объекта.
Реализация этого метода у Object проверяет, реализует ли объект у которого clone() был вызван интерфейс Cloneable(). Если нет, то выбрасывается CloneNotSupportedException. Если да, то создается объект того же класса, как исходный и его поля инициализируется теми же значениями.
Для некоторых классов стандартное поведение метода clone() работает отлично. Но если объект содержит ссылку на внешний объект, то возможно потребуется переопределить поведение метода clone(). В противном случае изменение внешнего объекта в одном классе приведет к его изменению в другом (полученном клонированием) классе.

public String toString() {
    return getClass().getName() + "@" + Integer.toHexString(hashCode());
}

public String toString() {

return getClass().getName() + "@" + Integer.toHexString(hashCode());

}

Возвращает строковое представление объекта. При переопределении метода рекомендуется возвращать краткий но информативный результат. Для класса Object метод toString() возвращает строку, содержащую имя класса, экземпляром которого является объект и шестнадцатеричное представление хэщ-кода объекта, разделенные символом “@”.

Методы notify(), notifyAll(), wait() объекта участвуют в синхронизации независимо запущенных потоков в программе.

public final native void notify();

1	public final native void notify();

public final native void notifyAll();

1	public final native void notifyAll();

public final native void wait(long timeout) throws InterruptedException;

1	public final native void wait(long timeout) throws InterruptedException;

public final void wait(long timeout, int nanos) throws InterruptedException {
    if (timeout &lt; 0) {
        throw new IllegalArgumentException("timeout value is negative");
    }
    if (nanos &lt; 0 || nanos &gt; 999999) {
       throw new IllegalArgumentException(
                            "nanosecond timeout value out of range");
    }
    if (nanos &gt;= 500000 || (nanos != 0 &amp;&amp; timeout == 0)) {
        timeout++;
    }
    wait(timeout);
}

public final void wait(long timeout, int nanos) throws InterruptedException {

if (timeout < 0) {

throw new IllegalArgumentException("timeout value is negative");

}

if (nanos < 0 || nanos > 999999) {

throw new IllegalArgumentException(

"nanosecond timeout value out of range");

}

if (nanos >= 500000 || (nanos != 0 && timeout == 0)) {

timeout++;

}

wait(timeout);

}

public final void wait() throws InterruptedException {
    wait(0);
}

public final void wait() throws InterruptedException {

wait(0);

}

protected void finalize() throws Throwable { }

1	protected void finalize() throws Throwable { }

Класс Object предоставляет callback метод finalize(), который может вызываться для объекта когда он становится “мусором”. Реализация finalize() у Object не делает ничего. Его можно переопределить для очистки, нарпимер свободных ресурсов.

Метод finalize() может быть вызван системой автоматически, но тот момент когда он будет вызван никак не определен. По этому нельзя пологаться на этот метод, что-бы сделать свою чистку. Следует заметить, что если объект доступен для сборки и в нем переопределен метод finalize(), то он не вызовется сразу, а поместится в очередь, которая обрабатывается специально созданным для этого потоком.

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

Краткая выдержка про использование finalize (Джошуа Блох):
1. finalize() можно использовать только в двух случаях:
1.1. Проверка/подчистка ресурсов с логированием
1.2. При работе с нативным кодом, который не критичен к утечке ресурсов
2. finalize() замедляет работу GC по очистке объекта в 430 раз
3. finalize() может быть не вызван

Источник

Компилируем Java код в коммандной строке

June 9, 2014 by delfin

В последнее время, с развитием различных IDE, разработчикам очень редко, а в некоторых случаях и никогда, не приходилось компилить Java класс в коммандной строке. Ирония заключается в том, что иногда такой скил весьма полезен при работе на удаленной машине, где нет возможности развернуть тот же Eclipse и полноценно собрать проект. Конечно же, это накладывает особые ограничения на написание Java кода и использование всякоразных thirdparties. К примеру, является целесобразным, я считаю, пихать весь функционал в один класс с main методом и пустым classpath дабы не париться потом с зависимостями и гроздьями вспомогательных классов. В таком случае, написанный Java, класс можно использовать схожим образом с использованием обычного скрипта. Естественно при условии, что пользователь легко может компилить и запускать Java код из коммандной строки.

Итак, допустим у нас есть Java файл HtmlDumper.java в пакете com.lab.html.

1. Открываем консоль в корне classpath (т.е. в директории из которой видно папку com).

cd <path_to_project>\src

1	cd <path_to_project>\src

2. Устанавливаем переменную среды JAVA_HOME

set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_25

1	set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_25

3. Компилируем Java код

"%JAVA_HOME%\bin\javac" -g com\lab\html\HtmlDumper.java

1	"%JAVA_HOME%\bin\javac" -g com\lab\html\HtmlDumper.java

4. После успешной компиляции можно запускать Java программу прямо из этой директории

"%JAVA_HOME%\bin\java" -cp . com.lab.html.HtmlDumper

1	"%JAVA_HOME%\bin\java" -cp . com.lab.html.HtmlDumper

Вот и все. Java код был успешно скомпилирован и выполнен.