Статична поведінка методу в багатопотоковому середовищі в Java

Існує просте дурне запитання, яке мене турбує і висуває кілька міркувань. Я хочу викинути всі сумніви щодо нижчезазначених питань.

class Clstest{

    public static String testStaticMethod(String inFileStr) {

        // section 0

        // section 1

        // do something with inFileStr

        // section 2

        // section 3

        return inFileStr;

    }

}

Припустимо, що п’ять потоків виконує дзвінок Clstest.testStaticMethod("arg-n")одночасно.

Тема 1 дзвінків Clstest.testStaticMethod("arg-1").

Коли нитка 1 знаходиться в розділі 1, нитка 2 дзвонить Clstest.testStaticMethod("arg-2").

Тоді що буде з Ниткою 1? Чи перейде він у стан сну?

Коли Тема 1 отримає шанс, чи відновить її виконання з розділу 1, де було призупинено?

Як це відбувається, коли один Clstest.testStaticMethodі той же Clstest.testStaticMethodрозділяється між усіма п’ятьма потоками?

Чи є можливість обмінятися inFileStrнадісланим декількома потоками?

Відповідь Ганса Пасанта хороша. Але я подумав, що спробую пояснити на трохи простішому рівні для всіх, хто стикається з цим і є новинкою для Java. Ось іде ..

Пам'ять у Java розбита на два види - купа і стеки. Купа - це місце, де живуть усі об’єкти, а стопки - там, де нитки виконують свою роботу. Кожен потік має свій стек і не може отримати доступ до стеків один одного. Кожен потік також має вказівник на код, який вказує на біт коду, який вони зараз працюють.

Коли потік починає виконувати новий метод, він зберігає аргументи та локальні змінні в цьому методі на власному стеку. Деякі з цих значень можуть бути вказівниками на об’єкти на купі. Якщо два потоки працюють один і той же метод одночасно, вони будуть мати свої вказівники коду, що вказують на цей метод, і матимуть власні копії аргументів та локальні змінні у своїх стеках. Вони будуть заважати один одному лише в тому випадку, якщо речі, що знаходяться на їхніх стеках, вказують на однакові предмети на купі. У цьому випадку можуть статися всілякі речі. Але, як зазначає Ганс, рядки незмінні (неможливо змінити), тому ми безпечні, якщо це єдиний об'єкт, яким «поділяються».

Так багато потоків можуть працювати одним методом. Вони можуть не працювати одночасно - це залежить від того, скільки ядер у вас на машині, оскільки JVM відображає потоки Java в потоки ОС, які заплановані на апаратні потоки. Отже, ви мало контролюєте спосіб переплетення цих потоків без використання складних механізмів синхронізації .

Зауважте, що спати - це те, що нитка робить для себе.

Чи перейде він у стан сну?

Ні, запуск потоку не впливає на інші потоки, доки вони навмисно не синхронізуються між собою. Якщо у вас є більше одного ядра процесора, як це роблять усі останні машини, ці потоки, ймовірно, виконуються в той самий час. Це стає трохи менше, коли ви запускаєте 5 ниток, оскільки у вашої машини може бути недостатньо ядер. Операційна система змушена вибирати між собою, даючи їм кожен час працювати. Завдання планувальника потоків. Потім потік не знаходитиметься у стані "сну", він просто призупиняється і чекає, коли планувальник потоків дасть йому можливість запуску. Він відновиться там, де його перервав планувальник.

Чи є можливість обміну inFileStr, що надсилається декількома потоками?

Немає такої можливості, потоки мають власний стек, тому будь-який аргумент методу та локальна змінна будуть унікальними для кожного потоку. Крім того, використання рядка гарантує, що ці потоки не можуть заважати один одному, оскільки рядки незмінні.

Не існує такої гарантії, якщо аргумент є посиланням на інший тип об'єкта, що змінюється. Або якщо сам метод використовує змінні, які є статичними або посилаються на об'єкти в купі. Синхронізація потрібна, коли потік модифікує об'єкт, а інший потік читає його. Замок ключове слово в мові С # це шаблонний спосіб реалізувати таку необхідну синхронізацію. Те, що метод є статичним , не означає, що така синхронізація ніколи не потрібна. Лише менш вірогідні, оскільки вам не доведеться турбуватися про те, що звертаються до одного об’єкта (спільний доступ до цього )