我一直在与PrintServiceLookup作战；CCD_ 2方法在具有初始磨合的应用程序中检测打印机的速度太慢。拥有100多台网络打印机的客户端报告称，执行此代码的行为在第一次运行时表现不佳。
在看到查找结果被缓存后，我最初在一个单独的线程中部署了一个伪查找（在启动时执行）。但是，对于特定的客户端，此解决方案不起作用。
我目前没有他们的环境，也看不出是什么导致了确切的性能问题。
我正在尝试查看PrintService是否支持给定的MediaSizeName，而不执行DocFlavor和AttributeSet的查找。所以我提取了所有可用的PrintService和默认的PrintService:
private static final PrintService[] PRINTSERVICES =
PrintServiceLookup.lookupPrintServices(null, null);
private static final PrintService DEFAULTSERVICE =
PrintServiceLookup.lookupDefaultPrintService();
然后，从客户端请求中获得PrintService和MediaSizeName。最后，我询问PrintService是否支持MediaSizeName：
private void checkPrintServiceForMediaSize(PrintService pservice) throws MediaSizeNotSupportedException{
if(!pservice.isAttributeValueSupported(_mediaSizeName,null,null))
throw new MediaSizeNotSupportedException("This media size is not supported by the selected printer.");
}
API声明当使用空DocFlavor和AttributeSet 调用isAttributeValueSupported(Attribute attrval,DocFlavor flavor,AttributeSet attributes)时
该方法告诉该打印服务是否支持给定的打印属性值，以用于某些可能的文档风格和属性集的组合
到目前为止，他的行为是正确的。但是，如果打印机支持所选的页面大小，我不完全确定这是否是执行的方式。
我将感谢您在这个问题上的反馈和经验。
更新
大约在我实施我的方法的时候，我的工作站决定出现严重的网络问题，我花了一段时间才弄清楚。最后，我的实现已经用网络工具SoftPerfect Connection Emulator（模拟网络负载）进行了测试，结果没有显著改善。
我将继续测试并更新此问题。希望我能找到一个解决方案，并与这里的人们分享。我猜最初的查找：
private static final PrintService[] PRINTSERVICES =
PrintServiceLookup.lookupPrintServices(null, null);
仍在引发问题。
更新2
测试版最终在客户端环境中进行了测试，打印对话框的性能提高了约5倍（在相同环境下，打印机的初始拉动时间约为1分钟，而在相同环境中约为5分钟）。然而，最初的等待时间是不可接受的，这是我目前能做的最好的时间。我们还从客户那里听说，正在使用打印服务器，根据评论（@Wardy）中的建议，我将朝着这个方向前进。希望我们能够利用打印服务器的优势。
更积极的缓存。让客户端执行一次查找，并在重新启动之间保持缓存。更好的做法是，将缓存保存到所有客户端都可以访问的中央数据存储中。
我假设网络打印机及其功能不会经常更改，但您最终必须更新缓存，但"谁"one_answers"何时"取决于您的环境。
对缓存的更新可以由在后台运行当前发现的客户端进行，如果检测到更改，则更新缓存。如果您有一个连续运行的中心组件，那么这将是一个可以以固定间隔进行检查的好地方。
如果你有某种目录服务，你可以在联系每台打印机之前，将其打印机列表与你缓存的打印机进行比较，以获得其减轻网络和cpu负载的功能。
如果打印机列表存储在LDAP中，您可以尝试使用LDAP查找打印机。