это довольно интересный вопрос, так как имеет ряд точек оптимизации.
Ваша идея о создании меньшего изображения, а затем о создании миниатюр, вероятно, хорошая, но первое, что я хотел бы сказать, если у вас есть изображение размером 75 МБ, тогда оно явно намного больше, чем 1024x768 - скорее всего, несколько его кратных. , в этом случае вы хотите убедиться, что вы масштабируете изображение, используя SCALE_FAST ( Image ). Вы хотите добиться того, чтобы при масштабировании изображение уменьшалось до меньшего размера, отбрасывая пиксели, а не пытаясь сделать что-то более привлекательное (и гораздо более дорогое), например, усреднение по площади. Вы можете даже заставить его работать быстрее, взяв int [] для изображения и выбрав каждый N-й элемент, чтобы создать новый int [] для нового изображения, уменьшенного по некоторому коэффициенту.
В этот момент у вас будет уменьшенное изображение, скажем, примерно 2000 к 2000 году. Затем вы можете взять это изображение и масштабировать его, используя что-то более приятное, отыскивая реальные эскизы, такие как SCALE_SMOOTH.
Я бы сказал, что вы должны не записать его на диск, если это вообще возможно (во время обработки в любом случае). Если вы можете выполнить операцию в памяти, это будет намного быстрее, и это вдвойне важно, когда есть параллелизм. Если на вашем сервере не запущен SSD, то выполнение двух операций с большим объемом диска, выполняемых одновременно (например, два из этих изображений одновременно масштабируются или один размер изменяется до двух разных размеров), заставит ваш диск перебиваться (так как шпиндель может читать только один поток за раз). Тогда вы будете зависеть от времени поиска, и вы быстро обнаружите, что сериализация всех операций будет намного быстрее, чем выполнение нескольких операций одновременно.
Я бы сказал, что нужно изменить их масштаб в памяти, затем записать их (синхронизировано) в ArrayList, а затем создать другой поток, последовательно считывающий эти изображения и сохраняющий их. Если вы не уверены, что я имею в виду, посмотрите мой ответ на другой вопрос здесь:
Производитель Потребительское решение на Java
Таким образом, вы распараллеливаете, где это полезно (операции с процессором), и выполняете запись в файл последовательно (избегая побоев).
Сказав, что вам нужно спросить себя, пойдет ли вам на пользу распараллеливание? Ваш сервер имеет несколько процессоров / ядер? Если нет, то это все спорный вопрос, и вам не следует беспокоиться о потоке, потому что это только потеряет ваше время.
В дополнение к этому, если вы ожидаете, что много этих изображений будут загружены одновременно, вам может не потребоваться распараллеливать обработку каждого изображения, так как у вас будет несколько потоков веб-сервера, каждый из которых будет обрабатывать одно изображение в большинстве случаев. время и это даст вам хорошее использование процессора более чем на одном ядре в любом случае. Например, если вы ожидаете, что в любое время будет постоянно загружаться 4 изображения, тогда это будет нормально использовать 4 ядра без дальнейшего распараллеливания.
И последнее замечание: при масштабировании изображений, когда у вас есть промежуточное изображение, вы можете установить предыдущее изображение в null, чтобы упростить сборку мусора. Это означает, что при создании миниатюр у вас будет только промежуточное изображение в памяти. , не оригинал большого размера.