Объект потокобезопасности - статичный или нет?
РЕДАКТИРОВАТЬ:
Не нужно [] вокруг output при использовании этой линии для вывода на выход -
output.push( [values[n][2], values[n][3], values[n][5]]);
Чтобы установить значения по строке, данные должны быть в этом формате -
[ row,
row ]
или
[ [1,2,3],
[4,5,6] ]
Cannot covert Array to Object[][] отображается ошибка, когда диапазон и формат значения не совпадают.
Попробуйте эту строку -
targetTab.getRange(1, 1, output.length, columns.length).setValues([output]);
5 ответов
Если объект блокировки должен быть статическим или нет, зависит от объекта, который вы хотите заблокировать. Если вы хотите заблокировать экземпляр класса, вы не можете использовать объект статической блокировки. Если вы хотите заблокировать статические данные, вы не можете использовать объект блокировки экземпляра. Так что, похоже, выбора нет.
Можно подумать об использовании статического объекта или объекта блокировки экземпляра для блокировки доступа к данным экземпляра, но это приводит к другому поведению. С объектом блокировки экземпляра вы блокируете только экземпляр, в то время как объект статической блокировки блокирует все экземпляры. Так что здесь тоже нет выбора для настройки производительности.
He claimed the reason is that static is run at runtime instead of compilation and would make that object slower for threads to lock than if it was non static.
This doesn't really make any sense - I think either the interviewer did not know what he was talking about, or maybe you misunderstood his point.
Используйте нестатический объект для блокировки всякий раз, когда вам нужно убедиться, что один и тот же экземпляр не обрабатывается разными потоками одновременно.
Допустим, у вас есть несколько классов List, с помощью специального метода Reorder, который принимает некоторые странные аргументы. Подумайте, нужно ли вам переупорядочивать 100 разных списков во время каких-либо параллельных процессов. Вам важно только, чтобы разные потоки не манипулировали одним и тем же списком в одно и то же время, так как это может повлиять на логику переупорядочения. Вам не нужна статическая блокировка, так как вам все равно, когда одновременно обрабатываются разные списки.
Простой пример сценария со статической блокировкой - это инициализация некоторых статических данных, где вы хотите чтобы убедиться, что логика загрузки запускается только один раз. Как какой-то Кэш или Синглтон.
The others are correct that the choice of using a static of instance field depends on what state (class-level or instance-level) that you need to lock, and there is no relevant difference in speed for the lock itself. BUT if you really only need to use instance data then your app could run much faster using lock(this) rather than locking out all threads from accessing the data of ANY instance. That might have been what the interviewer was getting at - in an application where multiple threads are only using instance data it should indeed run faster if you only lock the instance because it won't block other threads from using other instances.
Conversely if threads are accessing class-level (static) state then you need to lock them all with a single object. When I need to do this, a pattern I've used is to lock the type of the class like this:
[Редактировать - в конце концов, не очень хорошая идея, см. Комментарии ниже]
lock(typeof(MyClass))
{
// use class-level data
}
Это позволяет избежать необходимости создания поля статического объекта.
Иногда на собеседованиях я говорю что-то, что, как я знаю, неверно или что-то совершенно бессмысленное, чтобы увидеть, будет ли кандидат эффективно доказывать свою точку зрения или просто сдастся и согласится.
Да, и вот превосходная статья Джеффри Рихтера о правильном использовании замка. :)