JavaScript гарантированно будет однопоточным?

Question

Известно, что JavaScript является однопоточным во всех современных реализациях браузеров, но это указано в каком-либо стандарте или это просто по традиции? Совершенно безопасно предположить, что JavaScript всегда однопоточный?

Answer 1

Это хороший вопрос. Я хотел бы сказать "да". Я не могу

Считается, что JavaScript обычно имеет один поток выполнения, видимый для сценариев (*), поэтому при вводе встроенного сценария, прослушивателя событий или тайм-аута вы полностью контролируете себя до тех пор, пока не вернетесь с конца своего блока или функции.

(*: игнорирование вопроса о том, действительно ли браузеры реализуют свои движки JS, используя один поток ОС, или WebWorkers вводят другие ограниченные потоки выполнения.)

Тем не менее, на самом деле это не совсем верно, в подлых противных отношениях.

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

var l= document.getElementById('log');
var i= document.getElementById('inp');
i.onblur= function() {
    l.value+= 'blur\n';
};
setTimeout(function() {
    l.value+= 'log in\n';
    l.focus();
    l.value+= 'log out\n';
}, 100);
i.focus();

<textarea id="log" rows="20" cols="40"></textarea>
<input id="inp">

Результаты в log in, blur, log out на все кроме IE. Эти события происходят не только потому, что вы позвонили focus() напрямую, они могут произойти, потому что вы позвонили alert() или открылось всплывающее окно, или что-нибудь еще, что перемещает фокус.

Это также может привести к другим событиям. Например добавить i.onchange слушатель и введите что-то на входе до focus() вызов расфокусирует его, и порядок регистрации log in, change, blur, log out кроме оперы где log in, blur, log out, change и IE, где это (даже менее объяснимо) log in, change, log out, blur,

Точно так же вызов click() на элементе, который обеспечивает это вызывает onclick Обработчик сразу во всех браузерах (по крайней мере, это соответствует!).

(Я использую прямой on... свойства обработчика событий здесь, но то же самое происходит с addEventListener а также attachEvent.)

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

var l= document.getElementById('log');
document.getElementById('act').onclick= function() {
    l.value+= 'alert in\n';
    alert('alert!');
    l.value+= 'alert out\n';
};
window.onresize= function() {
    l.value+= 'resize\n';
};

<textarea id="log" rows="20" cols="40"></textarea>
<button id="act">alert</button>

Удар alert и вы получите модальное диалоговое окно. Больше сценарий не выполняется, пока вы не закроете этот диалог, да? Нету. Измените размер главного окна, и вы получите alert in, resize, alert out в текстовой области.

Вы можете подумать, что невозможно изменить размер окна, пока модальное диалоговое окно включено, но это не так: в Linux вы можете изменить размер окна так, как вам нравится; в Windows это не так просто, но вы можете сделать это, изменив разрешение экрана с большего на меньшее, где окно не помещается, в результате чего его размер изменяется.

Вы можете подумать, ну, это только resize (и, вероятно, еще несколько, как scroll), который может срабатывать, когда пользователь не имеет активного взаимодействия с браузером, потому что сценарий является многопоточным. И для одиночных окон вы можете быть правы. Но это все подходит к концу, как только вы выполняете межоконный сценарий. Для всех браузеров, кроме Safari, который блокирует все окна / вкладки / фреймы, когда любой из них занят, вы можете взаимодействовать с документом из кода другого документа, работая в отдельном потоке выполнения и вызывая любые связанные обработчики событий для Пожар.

Места, в которых события, которые вы можете вызвать, могут быть вызваны, пока скрипт все еще находится в потоке:

• когда модальные всплывающие окна (alert, confirm, prompt) открыты во всех браузерах, кроме Opera;

• в течение showModalDialog в браузерах, которые его поддерживают;

• диалоговое окно "Сценарий на этой странице может быть занят...", даже если вы решите продолжить выполнение сценария, позволяет запускать такие события, как изменение размера и размытие, и обрабатывать их, даже когда сценарий находится в середине занятый цикл, кроме как в Опере.

• Некоторое время назад для меня, в IE с плагином Sun Java, вызов любого метода в апплете мог привести к запуску событий и повторному вводу сценария. Это всегда была ошибка, чувствительная ко времени, и, возможно, с тех пор Sun исправила ее (я, конечно, на это надеюсь).

• наверное больше. Прошло много времени с тех пор, как я протестировал это, и с тех пор браузеры стали более сложными.

Таким образом, для большинства пользователей JavaScript, как правило, имеет строгий поток выполнения, управляемый событиями. На самом деле, такого нет. Неясно, насколько это просто ошибка, а какой умышленный дизайн, но если вы пишете сложные приложения, особенно кросс-оконные / фрейм-скриптовые, есть все шансы, что они могут вас укусить - и периодически, трудные для отладки способы.

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

Answer 2

Я бы сказал да - потому что практически весь существующий (по крайней мере, весь нетривиальный) код javascript сломался бы, если бы движок javascript браузера запускал его асинхронно.

Добавьте к этому тот факт, что HTML5 уже определяет Web Workers (явный, стандартизированный API для многопоточного кода JavaScript), вводить многопоточность в базовый Javascript будет в основном бессмысленно.

(Примечание для других комментаторов: хотя setTimeout/setIntervalСобытия загрузки по HTTP-запросу (XHR) и события пользовательского интерфейса (щелчок, фокус и т. Д.) Создают грубое впечатление многопоточности - все они по-прежнему выполняются на одной временной шкале - по одному за раз - так что даже если мы не будем Не знаю заранее порядка их выполнения, нет необходимости беспокоиться об изменении внешних условий во время выполнения обработчика событий, функции времени или обратного вызова XHR.)

Answer 3

Да, хотя при использовании любого из асинхронных API-интерфейсов, таких как setInterval и xmlhttp, могут возникать некоторые проблемы параллельного программирования (в основном, состояния гонки).

Answer 4

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

Я думаю, что однопоточная неблокирующая парадигма возникла из-за необходимости запускать javascript в браузерах, где пользовательский интерфейс никогда не должен блокировать.

Nodejs следовал подходу браузеров.

Однако движокRhino поддерживает запуск кода js в разных потоках. Выполнения не могут совместно использовать контекст, но они могут совместно использовать область. Для этого конкретного случая в документации говорится:

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

Из прочтения документации Rhino я заключаю, что кто-то может написать javascript api, который также порождает новые потоки javascript, но api будет специфичным для rhino (например, node может порождать только новый процесс).

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

Что касается браузеров и nodejs, я вижу это так:

• Весь код js выполняется в одном потоке?: Да.

• Может ли js-код вызывать запуск других потоков?: Да.

• Могут ли эти потоки изменить контекст выполнения js? Нет. Но они могут (прямо / косвенно (?)) Добавлять в очередь событий.

Таким образом, в случае браузеров и nodejs (и, вероятно, многих других движков) javascript не является многопоточным, а сами движки.

Answer 5

Да, хотя Internet Explorer 9 скомпилирует ваш Javascript в отдельном потоке для подготовки к выполнению в основном потоке. Это ничего не меняет для вас, как для программиста.

Answer 6

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

Answer 7

JavaScript/ECMAScript предназначен для жизни в среде хоста. То есть JavaScript на самом деле ничего не делает, если только хост-среда не решит проанализировать и выполнить данный сценарий и предоставить объекты среды, которые позволят JavaScript на самом деле быть полезным (например, DOM в браузерах).

Я думаю, что данная функция или блок скрипта будут выполняться построчно, и это гарантировано для JavaScript. Однако, возможно, среда хоста может выполнять несколько сценариев одновременно. Или среда хоста всегда может предоставить объект, который обеспечивает многопоточность. setTimeout а также setInterval являются примерами или, по крайней мере, псевдо-примерами среды хоста, обеспечивающей способ выполнения некоторого параллелизма (даже если это не совсем параллелизм).

Answer 8

@Bobince дает действительно непрозрачный ответ.

Вопреки ответу Мара Орлигссона, Javascript всегда однопоточный из-за этого простого факта: все в Javascript выполняется по одной временной шкале.

Это строгое определение однопоточного языка программирования.

Answer 9

Нет.

Я иду против толпы здесь, но терпите меня. Один JS-скрипт должен быть эффективно однопоточным, но это не значит, что его нельзя интерпретировать по-разному.

Допустим, у вас есть следующий код...

var list = [];
for (var i = 0; i < 10000; i++) {
  list[i] = i * i;
}

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

Первая нить

for (var i = 0; i < 5000; i++) {
  list[i] = i * i;
}

Вторая нить

for (var i = 5000; i < 10000; i++) {
  list[i] = i * i;
}

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

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

Если продолжить эту концепцию, возможно, что код можно будет аннотировать, чтобы позволить ВМ знать, что преобразовывать в многопоточный код.

// like "use strict" this enables certain features on compatible VMs.
"use parallel";

var list = [];

// This string, which has no effect on incompatible VMs, enables threading on
// this loop.
"parallel for";
for (var i = 0; i < 10000; i++) {
  list[i] = i * i;
}

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

Answer 10

Движок Javascript должен быть однопоточным, но среда выполнения Javascript не обязательно должна быть однопоточной.

Теперь, что такое движок Javascript? Это интерпретатор, который выполняет реальный код JS. Двигателю нужен хозяин. Он не может работать сам по себе. Хост - это среда выполнения Javascript.

Например, движок V8, работающий в браузере Chrome, является однопоточным. Браузер Chrome — это среда выполнения, и в нем есть другие процессы/потоки для поддержки движка V8.

Вы можете проверить эту статью , где это прекрасно объяснено. Если это поможет, не забудьте вернуться и проголосовать :)

Answer 11

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

В Javascript нет никакой поддержки многопоточности, по крайней мере, явно, поэтому это не имеет значения.

Answer 12

Я попробовал пример @bobince с небольшими изменениями:

<html>
<head>
    <title>Test</title>
</head>
<body>
    <textarea id="log" rows="20" cols="40"></textarea>
    <br />
    <button id="act">Run</button>
    <script type="text/javascript">
        let l= document.getElementById('log');
        let b = document.getElementById('act');
        let s = 0;

        b.addEventListener('click', function() {
            l.value += 'click begin\n';

            s = 10;
            let s2 = s;

            alert('alert!');

            s = s + s2;

            l.value += 'click end\n';
            l.value += `result = ${s}, should be ${s2 + s2}\n`;
            l.value += '----------\n';
        });

        window.addEventListener('resize', function() {
            if (s === 10) {
                s = 5;
            }

            l.value+= 'resize\n';
        });
    </script>
</body>
</html>

Итак, когда вы нажимаете Run, закрываете всплывающее окно оповещения и делаете "один поток", вы должны увидеть что-то вроде этого:

click begin
click end
result = 20, should be 20

Но если вы попытаетесь запустить это в стабильной версии Opera или Firefox в Windows и свернуть / свернуть окно с всплывающим предупреждением на экране, то будет что-то вроде этого:

click begin
resize
click end
result = 15, should be 20

Я не хочу сказать, что это "многопоточность", но какой-то фрагмент кода был выполнен в неподходящее время, и я этого не ожидал, и теперь у меня поврежденное состояние. И лучше узнать об этом поведении.

Answer 13

Попробуйте вложить две функции setTimeout друг в друга, и они будут вести себя многопоточно (т. Е. Внешний таймер не будет ожидать завершения внутреннего таймера перед выполнением своей функции).