JDeveloper 运行慢时，搜索到的办法通常有两类：一类修改界面绘制参数，另一类增加 JVM 内存。表面上都在改配置，但处理的是不同问题，不能只看到“提速”两个字就全部加上。

这里记录几项设置，分别对应界面卡顿、IDE 内存和 BPM/SOA 服务端内存。不同版本的配置路径可能不同，修改前先确认安装目录和启动时使用的 JDK。

可以先按现象缩小范围：

这些现象只能帮助定位方向。普通的编译或部署耗时，也可能需要从项目和服务日志继续排查。

一、界面卡顿：Java 2D 参数是一条排查线索

在 Windows 下使用 JDeveloper 10.1.3.3 时，可以尝试在 jdev.conf 末尾加入：

AddVMOption -Dsun.java2d.noddraw=true
AddVMOption -Dsun.java2d.ddoffscreen=false

在相应的安装目录下查找：

jdevbin\jdev\bin\jdev.conf

这两个参数与 Windows 下 Java 2D 的 DirectDraw 绘制路径有关，适合用于排查旧版 JDK 与显卡驱动、硬件加速之间的兼容问题。调整的是界面绘制方式，编译、部署等操作的耗时还需要另外观察。

sun.java2d.* 属于实现相关属性，不同 JDK 版本的绘制管线和支持情况可能不同。Oracle 的 Java SE 7 Java 2D 属性说明 列出了这些属性及适用限制，因此不能把两行配置当作所有环境通用的优化项。

先备份配置，修改后重启 IDE，再重复切换编辑器、滚动页面和打开设计视图等操作。如果显示问题没有改善，就恢复原配置，继续检查其他原因。

二、内存不足：调整 IDE 自己的堆

如果问题表现为打开较大项目后频繁停顿，或者明确出现堆内存不足提示，就需要检查 IDE 的 JVM 内存配置。

对于安装在 Middleware 目录下、使用以下配置布局的 JDeveloper，可以检查：

<Middleware_Home>\jdeveloper\ide\bin\ide.conf

不同版本的目录结构和配置加载方式可能不同，应先找到当前版本生效的配置。存在相同参数时修改原有项，不盲目重复追加。

参考设置如下：

AddVMOption -Xms512M
AddVMOption -Xmx1280M

这组配置表示初始堆为 512 MB，最大堆为 1280 MB：

最大堆是上限，不表示 Java 进程始终只占用这个数值的内存。这里的容量只是示例，实际取值需要结合项目大小和机器剩余内存。

调整时还要给操作系统、数据库和应用服务器留空间。Java 进程的总内存也不只有堆；如果把最大堆设得过大，导致系统频繁换页，反而可能更慢。32 位 JVM 的可用地址空间还有限制，不能直接照搬较大的 64 位配置。

三、BPM/SOA Server 的 JVM 参数

开发 BPM/SOA 应用时，还要区分 IDE 和服务端的内存设置。它们运行在不同进程中，给 JDeveloper 增加堆内存，并不会同时增加服务端的堆。

服务端可以从域目录下的这份启动脚本检查内存配置：

<Domain>\bin\setSOADomainEnv.cmd

脚本中可能使用 DEFAULT_MEM_ARGS 和 PORT_MEM_ARGS 两组变量。实际采用哪一组，要看对应版本启动脚本的分支以及后续是否覆盖，不能只凭变量名确定所有安装环境的行为。

下面是一组容量配置示例，只展示参数赋值，使用时应修改启动脚本中的对应分支：

set DEFAULT_MEM_ARGS=-Xms512m -Xmx1024m
set PORT_MEM_ARGS=-Xms3200m -Xmx3200m

如果服务使用的是 JDK 7 等仍采用永久代的 HotSpot JVM，还可以在对应分支中设置永久代大小：

set DEFAULT_MEM_ARGS=%DEFAULT_MEM_ARGS% -XX:PermSize=128m -XX:MaxPermSize=512m
set PORT_MEM_ARGS=%PORT_MEM_ARGS% -XX:PermSize=512m -XX:MaxPermSize=768m

PermSize 设置永久代初始大小，MaxPermSize 设置其上限。永久代与 Java 堆不是同一块空间，所以排查内存异常时要看完整信息：Java heap space 和 PermGen space 指向不同区域，只增加 -Xmx 不能解决永久代容量不足。

上面的 3200 MB 堆配置需要相应的 64 位 JVM 和足够的可用内存。示例容量并非必须值，应结合应用实际占用调整。

还要看清 JVM 版本：JDK 8 的 HotSpot 已移除永久代，这组永久代参数不能继续按旧含义使用。该变化见 JDK 8 兼容性说明。其他 JVM 实现是否接受这些参数，同样需要核对。

修改服务端参数后，需要重启对应服务，并检查启动日志中的最终参数。仅修改脚本并不能证明配置已经生效，更不能直接证明性能改善。

四、每次只调整一类设置

为了判断修改是否有效，我会按下面的顺序检查：

1. 记下出现问题的操作、错误信息，以及发生问题的是 IDE 还是服务端。
2. 确认该进程使用的 JDK、位数和配置文件，备份原配置。
3. 只调整与当前问题有关的一类设置，重启对应进程。
4. 用同一个项目重复相同操作，比较耗时、内存占用和错误是否重现。

如果同时改图形参数、IDE 内存和服务端内存，即使表现变好了，也很难知道是哪项起了作用。

对这类问题，我更愿意先记清“哪一个进程、哪一种卡顿、哪一份配置”。界面显示异常先看图形绘制线索，IDE 内存问题检查 IDE 的 JVM，服务端启动或运行问题再检查服务端 JVM。范围找准了，后面的参数调整才有意义。