J'ai une collection de De ma compréhension de la façon dont Cependant, je ne trouve rien dans la documentation qui dit qu'il est définitivement sûr de le faire. Puis-je supposer que c'est sûr? Je sais qu'il est possible de travailler sur des copies de l'enfant Sinon, est-il possible de faire de l'opération thread-coffre-fort sans copier des régions de l'image parent? bufferedimage , une image principale et des sous-intégres créés en appelant getsUtimage sur l'image principale. Les sous-mises ne se chevauchent pas. Je fais aussi des modifications au sous-mode et je veux diviser cela en plusieurs threads, un par subimage.
bufferedimage , raster et Databanduffer travail, ceci doit être en sécurité car:
bufferedimage (et son WritaBeraster et samplemodel ) est accessible d'un seul thread.
colormodel partagé est immutable
n'a aucun champ pouvant être modifié (la seule chose qui peut changer est des éléments du tableau de support.)
raster s mais je préférerais éviter cela en raison de contraintes de mémoire.
4 Réponses :
Je n'ai trouvé aucune preuve claire de la sécurité des threads de Au lieu d'un traitement simultané des sous-mètres de différents travailleurs, essayez de Procédez de nombreuses images dans la manière dont chaque travailleur consomme différents sous-géants de la même image. Le même travailleur traitera des sous -ges de la même image, mais de manière séquentielle. Vos travailleurs seraient occupés jusqu'à moins d'images que de restées des travailleurs. revenir ce problème:
À: bufferedimage , mais vous pouvez probablement résoudre votre problème la prochaine méthode:
Ensuite, il n'y a aucun avantage de fractionnement de l'image.
Je préférerais continuer à traiter les sous-intitulé d'une seule image dans plusieurs threads pour réduire la latence. Même s'il s'avère que cela nécessite une copie des sous -ges.
Avez-vous regardé à l'aide de JAI pour gérer vos "sous -ages" comme tuiles? Il semble que vous ayez une meilleure utilisation des ressources si vous n'avez pas à accrocher à l'instance de mémoire tampon de l'image d'origine ainsi que toute son instance de bufferedImage de sous-mode. Les informations sur JAI peuvent être trouvées ici: Jai Readme
Il y a une classe, TileDimage, qui implémente l'interface renduimage (en lui donnant un ancêtre commun avec Bufferedimage). Selon la documentation JAI:
L'utilisation de carrelage facilite également la Utilisation de threads multiples pour calcul. Précédemment attribué Les tuiles peuvent également être réutilisées pour sauver mémoire.
L'utilisation de l'une de ces implémentations de renduimage est souvent préférable à une bufferedimage de toute façon, car la bufferedimage conserve une instantanée d'image en mémoire de l'image entière. Jai utilise une chaîne de rendu et peut recycler des carreaux au besoin pour s'adapter à des contraintes de mémoire.
C'est une bonne analyse et cela me semble correct. Il n'y a pas de données partagées, un accès aussi concurrent devrait être bien. Cependant, vous avez besoin d'une sorte de garantie pour être sûr, plus d'une supposition éduquée qu'elle devrait fonctionner. Même si vous trouvez une déclaration indiquant que "BuffereImage est conçu pour être utilisé simultanément" - il n'y a aucune garantie que c'est le cas dans la pratique.
Pour être aussi sûr que possible, vous pouvez écrire un test d'unité simultané avec CONCOURS . Les instruments de harnais de test simultanés Votre code et injecte des commutateurs de contexte induits artificiellement pour exposer des bugs de concurrence. Cela testera le code BufferedImage et votre propre code afin que vous puissiez avoir un degré de confiance élevé qu'il est en sécurité.
Si aucune de ces réponses ne satisfait (suffisamment), vous pouvez faire quelque chose qui réglera de manière concluante la question à un prix lourd (?).
examinez la source de bufferedimage, de Databuffer, de raster, etc. C'est la seule façon.
Je l'ai déjà fait, mais être en sécurité sur une implémentation ne signifie pas nécessairement que cela sera en sécurité sur un autre.