我们找到了一种编程方式来避免生成这些文件-这听起来像是一种更好的内务处理方法。我在AXIS2-3919问题的评论中发布了它，但为了以防万一，我将复制它在这里：
实际上，每次创建AXIS配置上下文时，这些文件都会部署到temp文件夹中。此外，生成的Stub似乎可以通过构造函数接受现有的配置对象。因此，以下Spring配置帮助我们解决了这个问题（删除了不相关的bean和类名）：

<bean id="....Stub" factory-bean="...." factory-method="...." scope="request">
    <!-- this next element effects the proxying of the surrounding bean, 
        needed because .... will try to set the stub out of request scope -->
    <aop:scoped-proxy/>
    <constructor-arg index="0" >
        <!-- The WS stub is created here, and passed to the factory-method of ... as a parameter -->
        <bean class="com......ws.....Stub" scope="prototype">
            <constructor-arg ref="axisConfigContext" />
        </bean>
    </constructor-arg>
</bean>

<!-- Exists to avoid deployment of axis jar into temp dir for each request. See     AXIS2-3919 for more details. -->
<bean id="axisConfigContext" 
        class="org.apache.axis2.context.ConfigurationContextFactory" 
        factory-method="createConfigurationContextFromFileSystem">
    <constructor-arg index="0"><null /></constructor-arg>
    <constructor-arg index="1"><null /></constructor-arg>
</bean>

临时文件是在创建新的ConfigurationContext时创建的。因此，在静态块中只创建一次ConfigurationContext，并在所有后续调用中使用它。

private static ConfigurationContext configContext;

static {
     configContext = ConfigurationContextFactory.createConfigurationContextFromFileSystem(null, null);
}

public callService() {
    Stub stub = new Stub(configContext, END_POINT_URL);
    //code
}

如果不传递上下文，axis2将在每次调用时创建一个新上下文。

我尝试了创建静态块的解决方案（由proudandhonor提供），效果很好。它只为第一个请求创建临时文件。我还将Linux服务器上的uilimit更新为16000。现在我不需要删除临时文件。

private static ConfigurationContext configContext; 
static{   
   configContext = ConfigurationContextFactory.createConfigurationContextFromFileSystem(null, null);  
}

我一直在看同样的问题，看起来它可能在1.7.0版本中得到修复：
https://issues.apache.org/jira/browse/AXIS2-3919
我还没有尝试过，但我会更新这个评论，一旦我这样做。

如果你知道临时目录的路径，你可以通过cron每隔6、12..等时间运行rm -rf /path/to/temp/*。
或者你可以写你在linux系统上运行的bashscript，如果这个目录达到特定的大小，就清空它，并把它放在crontab中。

我无法找到任何其他方法，然后每天重新启动。除非您停止该进程，否则将不允许删除tmp文件。我已将系统属性"java.io.tmpdir"更改为其他具有更多磁盘空间的位置，这样至少不会耗尽磁盘空间。

System.setProperty("java.io.tmpdir","/opt/Axis2Temp");

其次，还有一个与这些文件相关的问题，在运行应用程序几个小时后，它会抛出Too many open files Exception，如下所示：
org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-7 org.apache.axis2.deployment.util.Utils.[createClassLoader]（856）-将jar提取到临时目录时出现异常：java.io.FileNotFoundException:/tmp/axis 2-tmp-9161756920591296931.tmp/axis 21477916618765108874 addressing-1.6.0.mar（打开的文件太多）：切换到交替类加载机制
org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-7 org.apache.axis2.deployment.util.Utils.[createClassLoader]（860）- java.io.FileNotFoundException：/tmp/axis 2-tmp-9161756920591296931.tmp/axis 21477916618765108874 addressing-1.6.0.mar（打开的文件太多）
为了解决这个问题，我将打开文件的ulimit增加到4000。

我最近遇到了这个确切的问题，这对我们来说是一个展示塞子。我有几个解决方案：
1.将java.io.tmpdir设置到一个不存在的目录。2这样做可能会产生一些不良后果！
1.创建一个定制版本的org.apache.axis2.deployment.util.Utils并编辑createClassLoader函数。将其部署在axis库之前的类路径中。此函数接受一个布尔值extractJars，它会导致文件被复制，如果这不可能（例如，如果tmp目录不存在），则类加载器将处理jar的原始副本。同样，这可能会有一些不希望的后果。这个主题有很多变体，我也看过添加一些代码来创建jar的单个副本，但我认为这个解决方案更好，因为它使用了现有的功能。下面是我的函数版本：

public static ClassLoader createClassLoader (URL[] urls,
                                    ClassLoader serviceClassLoader,
                                    boolean extractJars,
                                    File tmpDir,
                                    boolean  isChildFirstClassLoading) {
List embedded_jars = Utils.findLibJars(urls[0]);
return createDeploymentClassLoader(urls, serviceClassLoader,
                               embedded_jars, isChildFirstClassLoading);
}

希望这能帮上忙。