2012-06-12 8 views
0

Вот java-метод для шифрования записи из zip-файла и сохранения его как файла. Нет проблем с чтением и записью файла, поэтому нет ничего общего с строкой 2-5. проблема такова, как описано ниже ...Интервал между интервалами между потоками ExecutorService для сценария-движка

ExecutorService объект (ы), используемый для получения Zip-записи из ZipEntry[] массива (ze) 1by1 и выполнял их одновременно с фиксированным числом потоков. Каждый поток реализуется с объектом ScriptEngine из массива ScriptEngine (se). Когда поток заканчивает свое исполнение, механизм сценария будет свободен для другой записи. проблема заключается в первой партии ресурса потока (запись), исполнитель не равномерно разделяет записи. Таким образом, есть больше, чем запись отправленной на один двигатель, который вызывает тупиковая

  1. как задержать потока запустить пару миллисекунды после предыдущей?

    ИЛИ

  2. как очередь ресурс, когда двигатель сценарий занят. но я не могу видеть решение для этого:

Вот код:

static void encryptzip(ScriptEngine[] sc, String u, String k, ExecutorService es) throws... { 
    ZipFile zf = new ZipFile(u); 
    ZipEntry[] ze = getEntries(zf); 
    byte[][] zb = getArrayOfEntryBytes(zf, ze); 
    String p = getExtractionPath(u); 
    for(int i=0;i<ze.length;i++){ 
     encentry ee = new encentry(); 
     ee.bytes = zb[i]; 
     ee.entry = ze[i]; 
     ee.key = k; 
     ee.path = p; 
     ee.script = getFreeScriptEngine(sc); 
     es.execute(ee); 
    } 
} 
+0

Пожалуйста, отобразите код для 'getFreeScriptEngine()'. –

+0

им жаль. это секрет. u можете попробовать его urself – Dagon

+0

Как getFreeScriptEngine() знает, что движок скрипта бесплатный? Получает ли механизм сценария атомарно отмечать этот скриптовый движок как «используемый»? –

ответ

0

Независимо от того, что getFreeScriptEngine() делает это очень важно, чтобы ответить на этот вопрос.

Если я правильно и правильно, вам нужно выполнить алгоритм шифрования последовательно для бесплатных скриптовых движков. Это ваш главный источник параллелизма. Итак, вам нужно запланировать задачи шифрования в блокирующих очередях, которые блокируют одну и ту же блокировку (или монитор, как в шаблоне монитора Java) в качестве блокировки, которую необходимо удержать, чтобы правильно определить «свободный движок» в параллельном многопоточном , runtime (очень просто поставить монитор на «isEngineFree» логическую переменную, которая, возможно, имеет экземпляр «engine»?). После того, как вы определили правильную блокировку, вы можете выполнять операторы singleThreadedExecutor последовательно с «свободными» двигателями. Это можно добиться, передав «свободные движки» -блокированные очереди, которые будут хранить задачи шифрования, до услуг singleThreadedExecutor.

На самом деле существует более сложная механика блокировки, которая позволит вам использовать одну и ту же очередь блокировки для всех задач, сохраняя при этом стратегию выполнения одной задачи за свободный ход. Продвинутый раздел Java Concurrency in Practice, который представляет собой отличную книгу, чтобы посмотреть на нее, может дать вам некоторые указания по такому.

+0

Я второй параллелизм Java на практике, см. cout down latch. –