В соответствии с менеджером безопасности по умолчанию, если я создаю ExecutorService (ThreadPoolExecutor в этом случае), я не могу его закрыть, shutdown() просто вызывает checkPermission("modifyThread") и, таким образом, сразу же умирает:
import java.util.concurrent.*;
class A {
public static void main( String[] args) {
Thread ct = Thread.currentThread();
System.out.println("current thread: " + ct);
ct.checkAccess(); // we have access to our own thread...
ThreadPoolExecutor tpe = new ThreadPoolExecutor(
1, // one core thread
1, // doesn't matter because queue is unbounded
0, TimeUnit.SECONDS, // doesn't matter in this case
new LinkedBlockingQueue<Runnable>(), /* unbound queue for
* our single thread */
new ThreadFactory() {
public Thread newThread(Runnable r) {
// obviously never gets called as we don't add any work
System.out.println("making thread");
return new Thread(r);
}
}
);
tpe.shutdown(); // raises security exception
}
}
Sun JDK:
$java -Djava.security.manager A текущий поток: Thread [main, 5, main] Исключение в потоке "main" java.security.AccessControlException: доступ запрещен (java.lang.RuntimePermission modifyThread) в java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) в java.security.AccessController.checkPermission(AccessController.java:546) в java.lang.SecurityManager.checkPermission(SecurityManager.java:532) в java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1094) в A.main(A.java:22)
OpenJDK:
$java -Djava.security.manager A текущий поток: Thread [main, 5, main] Исключение в потоке "main" java.security.AccessControlException: доступ запрещен (java.lang.RuntimePermission modifyThread) в java.security.AccessControlContext.checkPermission(AccessControlContext.java:342) в java.security.AccessController.checkPermission(AccessController.java:553) в java.lang.SecurityManager.checkPermission(SecurityManager.java:549) в java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:711) в java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1351) в A.main(A.java:22)
Почему??????? Что являются последствиями безопасности создания пула потоков, который управляет только вам и отключает его? Это ошибка в реализациях, или я что-то не хватает?
Посмотрим, что спецификация для ExecutorService.shutdown говорит...
Инициирует упорядоченное завершение работы, в котором выполняются ранее поставленные задачи, но новые задачи не будут приняты. Вызов не имеет дополнительного эффекта, если он уже выключен.
Броски: SecurityException - если диспетчер безопасности существует и завершение работы этого ExecutorService может работать с потоками, которые вызывающему не разрешено изменять, поскольку он не поддерживает RuntimePermission ( "modifyThread" ) или метод проверки безопасности проверяет доступ.
Это... примерно так же неопределенно, как и получается. Спектр говорит ничего о любых "потоках системы", которые производятся в течение жизненного цикла ExecutorService, и, кроме того, он позволяет вам создавать свои собственные темы, что является доказательством того, что быть не "системными потоками", когда вы это делаете. (Как сделано выше в моем примере)
Похоже, что разработчики Java SE увидели, что возможно shutdown поднять SecurityException, поэтому они были такими же: "О, хорошо, я просто добавлю случайную проверку безопасности на соответствие"...
Дело в том, что чтение через источник OpenJDK (openjdk-6-src-b20-21_jun_2010), оказывается, что поток только любой создан, это вызов вашего поставляемого ThreadFactory (который никогда не вызывается в тестовом файле, так как я не создаю никакой работы, и я не звоню prestartCoreThread или preStartAllCoreThreads). Таким образом, проверка безопасности выполняется без видимых причин в OpenJDK ThreadPoolExecutor (как это делается в sun-jdk-1.6, но у меня нет источника):
/**
* Initiates an orderly shutdown in which previously submitted
* tasks are executed, but no new tasks will be accepted.
* Invocation has no additional effect if already shut down.
*
* @throws SecurityException {@inheritDoc}
*/
public void shutdown() {
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
checkShutdownAccess();
advanceRunState(SHUTDOWN);
interruptIdleWorkers();
onShutdown(); // hook for ScheduledThreadPoolExecutor
} finally {
mainLock.unlock();
}
tryTerminate();
}
checkShutdownAccess вызывается перед тем, как что-либо сделать...
/**
* If there is a security manager, makes sure caller has
* permission to shut down threads in general (see shutdownPerm).
* If this passes, additionally makes sure the caller is allowed
* to interrupt each worker thread. This might not be true even if
* first check passed, if the SecurityManager treats some threads
* specially.
*/
private void checkShutdownAccess() {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkPermission(shutdownPerm);
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
for (Worker w : workers)
security.checkAccess(w.thread);
} finally {
mainLock.unlock();
}
}
}
Как вы можете видеть, он безоговорочно вызывает checkPermission(shutdownPerm) в диспетчере безопасности. shutdownPerm определяется как... закрытый статический окончательный RuntimePermission shutdownPerm = новый RuntimePermission ( "modifyThread" );
... что совершенно не имеет смысла, насколько я могу сказать, потому что modifyThread подразумевает доступ к системным потокам, а там нет нити системы в игре здесь на самом деле, нет нити, потому что я не отправлял никаких работ или предварований, и даже если бы были потоки, они были бы моими потоками, потому что я прошел через ThreadFactory. Спецификация ничего не говорит о магическом умирании, кроме этого, если задействованы системные потоки (они отсутствуют), может быть SecurityException.
В принципе, почему я не могу просто удалить строку, которая проверяет доступ к системным потокам? Я не вижу никаких последствий для безопасности, требующих этого. И как никто другой не сталкивался с этой проблемой??? Я видел сообщение о проблеме, где они "разрешили" эту проблему, изменив вызов на shutdownNow на shutdown, очевидно, что это не исправило их для них.
