Преимущество использования Потока. Запустите по сравнению с QueueUserWorkItem
Упрощенное решение без использования регулярного выражения:
import android.text.InputFilter;
import android.text.Spanned;
/**
* Input filter that limits the number of decimal digits that are allowed to be
* entered.
*/
public class DecimalDigitsInputFilter implements InputFilter {
private final int decimalDigits;
/**
* Constructor.
*
* @param decimalDigits maximum decimal digits
*/
public DecimalDigitsInputFilter(int decimalDigits) {
this.decimalDigits = decimalDigits;
}
@Override
public CharSequence filter(CharSequence source,
int start,
int end,
Spanned dest,
int dstart,
int dend) {
int dotPos = -1;
int len = dest.length();
for (int i = 0; i < len; i++) {
char c = dest.charAt(i);
if (c == '.' || c == ',') {
dotPos = i;
break;
}
}
if (dotPos >= 0) {
// protects against many dots
if (source.equals(".") || source.equals(","))
{
return "";
}
// if the text is entered before the dot
if (dend <= dotPos) {
return null;
}
if (len - dotPos > decimalDigits) {
return "";
}
}
return null;
}
}
Для использования:
editText.setFilters(new InputFilter[] {new DecimalDigitsInputFilter(2)});
8 ответов
ThreadPool всегда там, однако, существует конечное число потоков, выделенных пулу на основе количества процессоров. Для приложений ASP.NET это обычно - плохая идея использовать Потоки, если Вы действительно не начинаетесь Асинхронный процесс и знаете, что не будет большого количества запросов (помните, что существует конечное число потоков в ThreadPool, который Вы совместно используете со всем работающим в Вашем AppDomain и существует реалистический предел на общее количество потоков, Вы хотите создать новый поток использования () также).
Для WinForms приложения рассматривают использование BackgroundWorker вместо того, чтобы использовать Поток или ThreadPool. Это использует ThreadPool, однако, это делает передачу между потоками легче на программисте здравого смысла мультипотока.
Обновленный
Избегайте использования ThreadPool. QueueUserWorkItem как Ваш пул приложений мог исчезнуть в любое время. Переместите эту работу снаружи или используйте WebBackgrounder, если Вы должны.
Из Hanselman.com - "Контрольный список: Что НЕ сделать в ASP.NET"
Пул потоков всегда доступен в приложениях .NET, независимо от его типа.
Стоимость запуска потока из пула потоков через ThreadPool.QueueUserWorkItem будет не более стоимости запуска собственного потока и может быть меньше.
Если вам просто нужно несколько потоков за короткий период, используйте пул потоков. Вот для чего это.
Одним из преимуществ использования Thread.Start() является то, что вы можете преднамеренно прервать поток позже. В ThreadPool у вас нет средств управления выполнением потока после того, как вы поставили его в очередь.
Это обсуждение заинтересует Вас
Когда я не должен использовать ThreadPool в .NET?
Я собирался делать это комментарием, но это стало слишком длинным.
CodemonkeyKing, кажется, совершил нападки на важном моменте, хотя не достаточно сильно, по-моему.
Существует много критериев, которые Вы могли бы использовать для описания кода. Это будет использоваться в длительном приложении или нет? Приложение Winforms или нет? Действительно ли это - клиентское приложение или Сервер? библиотека или автономный exe? и т.д. и т.д.
Кажется мне, что, если Ваш код будет работать в автономном приложении и Вы управляете всем окружающим кодом, затем можно прокрутить собственный пул потоков, запустить собственные потоки, и измерить и управлять стоимостью вокруг запуска потока, распараллелить задержку и потребление ресурсов. Или Вы могли использовать QUWI, но он не уничтожит Ваше приложение так или иначе. Вы свободны выбрать.
С другой стороны, если Ваш код упаковывается как библиотека, которой можно пользоваться в сервере - в ASP.NET, или возможно в приложении CLR SQL или Сервисе WCF - затем это - действительно плохая идея создать потоки. Необходимо использовать QUWI или некоторый другой механизм, который использует встроенный пул потоков (как BackgroundWorker). Если это должно использоваться в клиентских приложениях с другими библиотеками, еще раз, QUWI требуется. Предположите, что каждая библиотека, желающая использовать в своих интересах многоядерные компьютеры, прокрутила их собственные потоки. Был бы полный хаос в приложениях, которые пользовались больше, чем несколько библиотек. Необузданные потоки, все конкурирующие за те же ресурсы. Никакая централизованная координация #threads по сравнению с # процессорами.
Хорошая гигиена требует, чтобы библиотека, должна ли она быть использована в клиентских приложениях или приложениях для сервера, использовала общий пул потоков, и это означает QUWI.
Последняя вещь понять является этим;
Управляемый поток является или фоновым потоком или приоритетным потоком. Фоновые потоки идентичны приоритетным потокам за одним исключением: фоновый поток не поддерживает среду управляемого выполнения в рабочем состоянии. После того как все приоритетные потоки были остановлены в управляемом процессе (где .exe файл является управляемой сборкой), система останавливает все фоновые потоки и закрывается.
Потоки, которые принадлежат управляемому пулу потоков (то есть, потоки, свойство IsThreadPoolThread которых верно) являются фоновыми потоками. Все потоки, которые входят в среду управляемого выполнения из неуправляемого кода, отмечены как фоновые потоки. Все потоки, сгенерированные путем создания и запуска объекта нового потока, приоритетными потоками по умолчанию.
Если Вы используете поток, чтобы контролировать действие, такое как сокетное соединение, установить его свойство IsBackground на истинный так, чтобы поток не препятствовал тому, чтобы Ваш процесс завершился.
от сайта MSDN.
Если Ваши задачи будут коротки, то Вы будете, скорее всего, видеть намного лучшую производительность путем планирования задач на пул потоков через QueueUserWorkItem или BeginInvoke, поскольку Вы избегаете повторной стоимости создания и уничтожения Ваших собственных потоков.
Пул потоков, очевидно, платит за создание потоков также, но это снова использует потоки, таким образом, Вы не оплачиваете стоимость на задачу.
Можно также хотеть смотреть на Поточную обработку в C# (бесплатная электронная книга).
При создании собственных потоков имеет смысл запускать их на первом использовании и затем позволять им бродить вокруг некоторое время в случае, если Вам нужны они снова - Вы заставляете неактивный поток ожидать на событии, таким образом, можно повторно активировать его путем передачи сигналов о событии, и после того, как достаточно долгое время протечет, поток разбудит себя и выход, исправляя неиспользованные ресурсы. Путем сохранения небольшого количества неактивных потоков готовым быть снова использованными, Вы уменьшаете издержки постоянного создания и уничтожения потоков (который является значительным для достаточно недолгих операций).
Но это в основном, что очередь потока уже делает для Вас - таким образом, можно также использовать ее. Это - решенная проблема.
Подобные дебаты раньше происходили в сообществе C++ о строках, хотите верьте, хотите нет. Если каждый из нас пишет наш собственный строковый класс, или если мы используем std::string? Ответ зависит от того, хотите ли Вы изучить, как записать строковый класс, или Вы сделаны с этим, и Вы хотите продолжить изобретение чего-то нового.
Вот еще одно преимущество использования ThreadPool.QueueUserWorkItem.
У меня есть приложение winforms, у которого есть сердцебиение. Первоначально я реализовал это с помощью
heartbeat = new Thread(HeartbeatDoWork);
heartbeat.Start();
, который отлично работает в 98% случаев. Однако, когда приложение закрыто, иногда оно не «умирает» должным образом, т.е. процесс все еще виден в диспетчере задач.
Короче говоря, сердцебиение опубликовало событие, и оно обрабатывало событие (CAB pub / sub), где оно «зависало».
Исправить это несложно, просто используйте это
ThreadPool.QueueUserWorkItem(HeartbeatDoWork);
Я уверен, что есть несколько дополнительных вещей, которые я мог бы сделать при выделении моего собственного потока, и он будет должным образом очищен, но это проще, быстрее и легче понять ... ThreadPool делает всю работу за меня.