Можно ли контролировать количество времени, которое каждый поток выполняет в Java? - PullRequest
3 голосов
/ 23 октября 2011

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

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

Возможно ли сделать это с потоками? В данный момент я помещаю сон в поток, выполняющий обработку, но время вставки изменяется в зависимости от машины. Есть ли другой способ, которым я могу сделать это? Способ использования синхронизации потоков внутри моей программы?

Ответы [ 3 ]

4 голосов
/ 23 октября 2011

Вы можете увеличить приоритет потока, используя Thread.setPriority (...) , но это не идеально.

Возможно, вы можете использовать некоторую форму очереди блокировкииз пакета java.util.concurrent , чтобы заставить один поток ждать, пока другой поток что-то делает.Например, SynchronousQueue может использоваться для отправки сообщения из одного потока в другой поток о том, что теперь он может что-то делать.

Другой подход заключается в использовании Runnables вместо Threads и отправке Runnables исполнителю, например ThreadPoolExecutor .Этому исполнителю будет поручено убедиться, что Runnables используют изрядное количество времени.

2 голосов
/ 23 октября 2011

Первое, что нужно упомянуть, это то, что приоритет потока сам по себе не означает «долю ЦП».Кажется, существует много путаницы в том, что на самом деле означает приоритет потока, отчасти потому, что он на самом деле означает разные вещи под разными ОС.Если вы работаете в Linux, это на самом деле означает что-то близкое к относительной доле процессора.Но под Windows это точно не так.Таким образом, в случае, если это поможет, вы, во-первых, захотите взглянуть на некоторую информацию, которую я недавно скомпилировал о приоритетах потоков в Java , которая объясняет, что на самом деле означают приоритеты потоков в разных системах.

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

Однако яЯ не уверен, что это действительно поможет вашей задаче.

Как я понимаю, в основном у вас есть задача вставки, которая является шагом определения скорости.В обычных обстоятельствах маловероятно, что система «намеренно выделяет меньше ресурсов ЦП, чем может или нужно» потоку, выполняющему эту вставку.

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

Если вставка относится к стандартной системе БД, мне интересно, действительно ли эта вставка ужасно ограничена ЦП?

2 голосов
/ 23 октября 2011

Один из способов - установить приоритет потока обработки ниже, чем другой. Но будьте осторожны, это не рекомендуется, так как это не сделает вашу платформу независимой. (Приоритеты различных потоков на разных платформах ведут себя по-разному).

Другим способом будет использование службы, в которой поток базы данных будет продолжать отправлять сообщения о своем текущем состоянии (возможно, с некоторым флагом «aboutToOver»).

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

...