精华内容
下载资源
问答
  • 需要支持上传文件,并且在上传的过程中通过流式的方式生成md5校验码,然后好需要利用这个输入流来生成本地预览文件,而InputStrream是只能读一次的,并不能重复读,所以在这里就需要进行流的复制。 解释一下,...

    最近因为一个项目需求,需要支持上传文件,并且在上传的过程中通过流式的方式生成md5校验码,然后好需要利用这个输入流来生成本地预览文件,而InputStrream是只能读一次的,并不能重复读,所以在这里就需要进行流的复制。

    解释一下,fileUpload是自定义的文件Model实体。

      // 生产文件md5校验码,并且复制fileUpload.getInputStream(),否则inputStream只能读取一次
            HashMap<String, Object> map = CopyStreamUtils.copyInputStream(fileUpload.getInputStream());
            
            // 因为之前已经被读取了,需要重新设置inputStream
            fileUpload.setInputStream((InputStream) map.get("inputStream"));
            String MD5Code = (String) map.get("md5");
       
            System.out.println("MD5校验码为------" + MD5Code);

    CopyStreamUtils主要是用来复制流和生产md5校验码,一边复制一边生产,减少资源的消耗。(其实不能拿来当工具类,杂交了复制流和生产md5的功能QAQ)

    public class CopyStreamUtils {
    
    	/**
    	 * @param inputStream
    	 * @return
    	 */
    	public static HashMap<String, Object> copyInputStream(InputStream inputStream) {
    		
    		/* 
    		 * 	因为inputStream只能读取一次,
    		 * 	所以将其进行复制
    		 * 	复制方法是通过定义一个byteArrayOutputStream
    		 * 	然后将byteArrayOutputStream转化为InputStream
    		 * 	但是这样存在一个问题,就是当文件比较大的时候,会出现内存溢出
    		 * 	将jvm参数调整也效果不佳
    		 * 	所以解决方案为采用分段的方法,将原本的inputStream分成很多小的inputStream
    		 * 	然后通过SequenceInputStream进行合并输入流
    		 * 	合并后的SequenceInputStream和原来的输入流相同,达到复制的效果
    		 * */
    		
    		ByteArrayOutputStream baos = null;
    
    		// 每次读取1024字节
    		byte[] buffer = new byte[1024];
    		int readNum ;
    		
    		// 定义一个Vector,用来存储分段后的小的InputStream,最后用于构造SequenceInputStream和并流
    		Vector<InputStream> streams = new Vector<InputStream>();
    		
    		/*   为提高效率,在此处进行流处理的时候,直接进行md5校验码的生成,节省资源         */
    		String MD5String = "";
    		InputStream sequenceInputStream = null;
    		
    		try {
    			while ((readNum = inputStream.read(buffer)) > -1) {
    				baos = new ByteArrayOutputStream();
    				baos.write(buffer, 0, readNum);
    			
    				// 更新md5校验码的输入流
    				Md5Utils.updateFileMD5String(buffer, readNum);
    				
    				
    				// 分段的复制inputStream,每次将新产生的小段流与原来的合并
    				streams.add(new ByteArrayInputStream(baos.toByteArray()));
    				
    				/* 不同于其他输出流,二进制流无法通过flush进行刷新,
    				 * 所以只能通过close之后再重新new来充值二进制流
    				 * */
    				baos.close();
    			}
    			
    			// 生成md5校验码
    			MD5String = Md5Utils.getFileMD5String() ;
    			// 通过之前的分段的小的inputStream进行构造合并流
    			Enumeration<InputStream> e = streams.elements();
    			sequenceInputStream = new SequenceInputStream(e);
    			
    		} catch (Exception e) {
    			// TODO Auto-generated catch block
    			e.printStackTrace();
    		}
    
    		HashMap<String, Object> map = new HashMap<String, Object>();
    		map.put("md5", MD5String);
    		map.put("inputStream", sequenceInputStream);
    		
    		return map;
    	}

    生产文件的md5校验码,本来直接通过输入流就行,但是考虑到需要上面的复制流,就增加了一个updateFileMD5String方法来更新文件的输入流,然后将所有字节进行生成校验。

    public class Md5Utils {
    
    	private static final Logger logger = LoggerFactory.getLogger(Md5Utils.class);
    
    	protected static char[] hexDegists = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e',
    			'f' };
    
    	protected static MessageDigest md5 = null;
    
    	static {
    		try {
    			md5 = MessageDigest.getInstance("MD5");
    		} catch (NoSuchAlgorithmException nsae) {
    			// TODO: handle exception
    			logger.info(Md5Utils.class.getName() + "初始化失败,MessageDigest不支持md5!");
    			nsae.printStackTrace();
    		}
    	}
    
    	/**
    	 * 获取md5校验码
    	 * @param inputStream
    	 * @return
    	 * @throws IOException
    	 */
    	public static String getFileMD5String(java.io.InputStream inputStream) throws IOException {
    
    		// 每次读取1024字节
    		byte[] buffer = new byte[1024];
    		int readNum = 0;
    
    		while ((readNum = inputStream.read(buffer)) > 0) {
    			md5.update(buffer, 0, readNum);
    		}
    		inputStream.close();
    
    		return bufferToHex(md5.digest());
    	}
    
    	/**
    	 * 更新需要校验的文件输入流
    	 * @param bs
    	 * @return
    	 * @throws IOException
    	 */
    	public static void updateFileMD5String(byte[] bs, int readNum) throws IOException {
    		// 每次读取bs字节,更新MD5输入流
    		md5.update(bs, 0, readNum);
    	}
    
    	/**
    	 * 返回md5校验码
    	 * @return
    	 * @throws IOException
    	 */
    	public static String getFileMD5String() throws IOException {
    		return bufferToHex(md5.digest());
    	}
    
    	private static String bufferToHex(byte[] bytes) {
    		return bufferToHex(bytes, 0, bytes.length);
    	}
    
    	private static String bufferToHex(byte[] bytes, int m, int n) {
    		StringBuffer stringBuffer = new StringBuffer(n * 2);
    		int k = m + n;
    		for (int i = m; i < k; i++) {
    			appendHexPair(bytes[i], stringBuffer);
    		}
    
    		return stringBuffer.toString();
    	}
    
    	private static void appendHexPair(byte bt, StringBuffer stringBuffer) {
    		// 取字节中高四位进行转换
    		char ch0 = hexDegists[(bt & 0xf0) >> 4];
    		// 取字节中低四位进行转换
    		char ch1 = hexDegists[(bt & 0xf)];
    
    		stringBuffer.append(ch0);
    		stringBuffer.append(ch1);
    	}
    }

     

    接下来说一说遇到的坑,为了完成复制流,最开始是全部将InputStream全部通过ByteArrayOutputStream来转储,然后通过ByteArrayOutputStream.toByteArray()方法转化为byte,通过InputStream(byte[] byte)构造新的输入流,从而达到复制流的效果。这样的做法适合比较小的文件,当文件比较大(我自己这边测试的是上传600M的文件)就会出现内存溢出,网上查了很多才知道不应把所有的byte都存在内存中。所以想要分段写入,或者刷新ByteArrayOutputStream,

          刚开始的时候用输出流的flush方法,但是一直没用(这个坑了我好久),后面才知道字节流无法flush刷新。所以只能通过最蠢笨的办法,每次都close掉字节流,然后读下一个缓冲区的时候重新new,结果成功。

        最后通过合并流SequenceInputStream将每一小段inputStream合并成一个完整的输入流。从而达到复制流的效果。

     

    其实最开始用的是common.io的copyInputStreamToFile(InputStream,File),但是老大说要改,然后就折腾了一天。。。。。。。

    展开全文
  • 请先前往《Spring内存溢出问题》查看问题,大体问题就是突然间内存飙升,且CPU使用率非常高。   问题分析 通过内存dump分析发现内存中某个key会有几百万个,而且观察这些key会发现有时候是org.springframework....

    请先前往《Spring内存溢出问题》查看问题,大体问题就是突然间内存飙升,且CPU使用率非常高。

     

    问题分析

    通过内存dump分析发现内存中某个key会有几百万个,而且观察这些key会发现有时候是org.springframework.web.servlet.DispatcherServlet.LOCALE_RESOLVER,有时候又变成org.springframework.web.servlet.DispatcherServlet.THEME_RESOLVER,每次可能不一样。

     

    这个key是springmvc放到request中的属性key,而且一个key不可能放到request多次啊,因为request attributes本身通过HashMap存储,且线程不安全;造成这个问题的能想到的就是线程绑定变量泄露/并发操作request。

     

    但是问题通过观察应用,没有使用ThreadLocal模式,那么唯一可能就是并发操作request属性造成的。

     

    另外,通过观察日志,发现如下异常:

    1. [com.trs.core.frame.exceptions.handlers.ExceptionHandler] [ERROR] 2013-12-24 01:03:42 : No modifications are allowed to a locked ParameterMap   
    2. java.lang.IllegalStateException: No modifications are allowed to a locked ParameterMap  
    3.     at org.apache.catalina.util.ParameterMap.put(ParameterMap.java:166)  
    4.     at org.apache.catalina.connector.Request.getParameterMap(Request.java:1112)  
    5.     at org.apache.catalina.connector.RequestFacade.getParameterMap(RequestFacade.java:414)  
    6.     at javax.servlet.ServletRequestWrapper.getParameterMap(ServletRequestWrapper.java:166)  

    抛出这个异常的唯一原因就是并发操作request造成的。更加肯定了是并发使用request造成的。

     

    分析源代码

    1. public class ParamFilter implements Filter {  
    2.      
    3.     //省略部分代码  
    4.           
    5.     private ParamFilterWrapper wrapper;  
    6.       
    7.     public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {  
    8.         wrapper = new ParamFilterWrapper((HttpServletRequest) request);  
    9.         chain.doFilter(wrapper, response);  
    10.     }   
    11. }  

    发现没有,wrapper竟然是实例变量。

     

    我们知道Servlet规范规定Servlet、Filter默认是单实例,即线程不安全的;假设我们有两个线程P1和P2,如果以如下方式访问:

                          P1                                         P2

    01                  wrapper=request1

    02                                                               wrapper=request2

    03                  doFilter(wrapper)

     

    发现没有,P1线程使用了P2线程的request,因此就是多线程访问request了;很可能就会遇到如上问题。大家还应该知道HashMap多线程操作时可能会遇到死循环问题,具体可以参考《疫苗:Java HashMap的死循环》。

     

    对于Servlet、Filter等请务必以线程安全的方式进行操作。对于开发人员来说,建议读读Servlet规范,中文版请参考之前翻译的《Servlet 3.1规范[翻译] 》。

    展开全文
  • 上传大文件内存溢出错误OutOfMemory

    万次阅读 2015-02-23 23:20:27
    本来以前的项目框架里已经有现成的代码了,是用的springMVC文件上传下载的框架,但是以前都传的小文件,没什么问题,这次需要上传大文件,就老是报错了。 搜索原因的时候,发现好像这套框架是网络里面流传得比较...


    最近一个项目要做大的视频文件的上传和下载。本来以前的项目框架里已经有现成的代码了,是用的springMVC文件上传下载的框架,但是以前都传的小文件,没什么问题,这次需要上传大文件,就老是报错了。


    搜索原因的时候,发现好像这套框架是网络里面流传得比较广的,也算是bug吧,所以贴出来了。


    可惜,看不到上传文件的源码,(因为源码在领导那里,他老人家太忙)。反正最后就是各种折腾,然后找到原因了的。


    原因:


    看了代码,FileManagerAction里面的上传方法,应该是先将文件传到tomcat服务器的一个临时文件里面,再通过spring包内置的FileCopyUtils.copy(srcMFile.getBytes(), descFile)方法,将它复制到所要上传到的目标文件夹去。


    这个copy方法调用了commons-fileupload包里DiskFileItem类的get()方法,其中有一句代码是

    byte[] fileData = new byte[(int) getSize()];

    而这其中的getSize()方法的返回值是上文提到的copy方法的第一个参数srcMFile.getBytes()的值,也就是整个文件的大小的字节数。以前文件比较小的时候倒没什么关系,new了一个比较小长度的byte[]还能撑住,可是文件大了的时候,就不行了,就内存溢出了。


    找到原因了要怎么解决呢,反正脑子是不够用了,所以就索性yahoo了一把。(没了谷歌,也就只有yahoo了)。然后看到了这篇问答,多少有点启发。

    http://stackoverflow.com/questions/1693810/how-can-i-avoid-outofmemoryerrors-when-using-commons-fileuploads-diskfileitem-t  


    解决办法:

    FileCopyUtils的copy方法有几个重载的方法,选择用参数为IO流的方法就不会报错。即是改为:

    FileCopyUtils.copy(srcMFile.getInputStream(),new FileOutputStream(destFile));

    就OK 了。


    问题:

    虽然这样解决了大文件上传的问题,但是因为文件比较大,copy的耗时可能会比较长,用户体验度有待改善。


    ============================================================================================

    另外,之前还遇到过一个报错SizeLimitExceedException,这个和配置文件里设置的文件大小有关系。在multipartResolver那个bean里配置的。


    搜索原因的时候,发现好像这套框架是网络里面流传得比较广的,也算是bug吧,所以贴出来了。
    展开全文
  • 转自:http://hi.baidu.com/fvsd3/blog/item/9baec09a301bdebcc9eaf4a2.html 一、JVM内存区域组成  java把内存分四种:  1、栈区(stack segment)— 由编译器自动分配释放,存放函数的参数值,局

    转自:http://hi.baidu.com/fvsd3/blog/item/9baec09a301bdebcc9eaf4a2.html

    一、JVM内存区域组成 

    java把内存分四种: 
    1、栈区(stack segment)— 由编译器自动分配释放,存放函数的参数值,局部变量的值等,具体方法执行结束之后,系统自动释放内存资源 
    2、堆区(heap segment) — 一般由程序员分配释放,存放由new创建的对象和数组,jvm不定时查看这个对象,如果没有引用指向这个对象就回收 
    3、静态区(data segment)— 存放全局变量,静态变量和字符串常量,不释放 
    4、代码区(code segment)— 存放程序中方法的二进制代码,而且是多个对象 共享一个代码空间区域 

    在方法(代码块)中定义一个变量时,java就在栈中为这个变量分配内存空间,当超过变量的作用域后,java会自动释放掉为该变量所分配的内存空间;在堆中分配的内存由java虚拟机的自动垃圾回收器来管理,堆的优势是可以动态分配内存大小,生存期也不必事先告诉编译器,因为它是在运行时动态分配内存的。缺点就是要在运行时动态分配内存,存取速度较慢;栈的优势是存取速度比堆要快,缺点是存在栈中的数据大小与生存期必须是确定的无灵活性。 

    java堆由Perm区和Heap区组成,Heap区则由Old区和New区组成,而New区又分为Eden区, From区, To区,Heap = {Old + NEW = { Eden, From, To } },见图1所示。



    Heap区分两大块,一块是 NEW Generation, 另一块是Old Generation. 在NewGeneration中,有一个叫Eden的空间,主要是用来存放新生的对象,还有两个Survivor Spaces(from,to),它们用来存放每次垃圾回收后存活下来的对象。在Old Generation中,主要存放应用程序中生命周期长的内存对象,还有个PermanentGeneration,主要用来放JVM自己的反射对象,比如类对象和方法对象等。 

    在NewGeneration块中,垃圾回收一般用Copying的算法,速度快。每次GC的时候,存活下来的对象首先由Eden拷贝到某个SurvivorSpace, 当Survivor Space空间满了后, 剩下的live对象就被直接拷贝到OldGeneration中去。因此,每次GC后,Eden内存块会被清空。在OldGeneration块中,垃圾回收一般用mark-compact的算法,速度慢些,但减少内存要求. 

    垃圾回收分多级,0级为全部(Full)的垃圾回收,会回收OLD段中的垃圾;1级或以上为部分垃圾回收,只会回收NEW中的垃圾,内存溢出通常发生于OLD段或Perm段垃圾回收后,仍然无内存空间容纳新的Java对象的情况。 

    JVM调用GC的频度还是很高的,主要两种情况下进行垃圾回收:当应用程序线程空闲;另一个是java内存堆不足时,会不断调用GC,若连续回收都解决不了内存堆不足的问题时,就会报out of memory错误。因为这个异常根据系统运行环境决定,所以无法预期它何时出现。 

    根据GC的机制,程序的运行会引起系统运行环境的变化,增加GC的触发机会。为了避免这些问题,程序的设计和编写就应避免垃圾对象的内存占用和GC的开销。显示调用System.GC()只能建议JVM需要在内存中对垃圾对象进行回收,但不是必须马上回收,一个是并不能解决内存资源耗空的局面,另外也会增加GC的消耗。 


    当一个URL被访问时,内存申请过程如下: 
    A. JVM会试图为相关Java对象在Eden中初始化一块内存区域 
    B. 当Eden空间足够时,内存申请结束。否则到下一步 
    C. JVM试图释放在Eden中所有不活跃的对象(这属于1或更高级的垃圾回收), 释放后若Eden空间仍然不足以放入新对象,则试图将部分Eden中活跃对象放入Survivor区 
    D. Survivor区被用来作为Eden及OLD的中间交换区域,当OLD区空间足够时,Survivor区的对象会被移到Old区,否则会被保留在Survivor区 
    E. 当OLD区空间不够时,JVM会在OLD区进行完全的垃圾收集(0级) 
    F. 完全垃圾收集后,若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象,导致JVM无法在Eden区为新对象创建内存区域,则出现"out of memory错误" 

    二、内存溢出类型 
    1、java.lang.OutOfMemoryError: PermGen space 
    JVM管理两种类型的内存,堆和非堆。堆是给开发人员用的,是在JVM启动时创建;非堆是留给JVM自己用的,用来存放类的信息的。它和堆不同,运行期内GC不会释放空间。如果webapp用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小,超出了也会导致这块内存的占用过多造成溢出,或者tomcat热部署时侯不会清理前面加载的环境,只会将context更改为新部署的,非堆存的内容就会越来越多。 


    2、java.lang.OutOfMemoryError: Java heap space 
    这种内存溢出是最常见的情况之一,主要体现在Old区的溢出,产生的原因可能是:1) 设置的内存参数过小(ms/mx, NewSize/MaxNewSize);2) 程序问题。Heapspace其默认空间(即-Xms)是物理内存的1/64,最大空间(-Xmx)是物理内存的1/4。如果内存剩余不到40%,JVM就会增大堆到Xmx设置的值,内存剩余超过70%,JVM就会减小堆到Xms设置的值。所以服务器的Xmx和Xms设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小。假设物理内存无限大,那么JVM内存的最大值跟操作系统有关,一般32位机是1.5g到3g之间,而64位的就不会有限制了。 

    注意:如果Xms超过了Xmx值,或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。 

    3、java.lang.OutOfMemoryError: c heap space 
    系统对C Heap没有限制,故C Heap发生问题时,Java进程所占内存会持续增长,直到占用所有可用系统内存 

    4、其他 
    JVM有2个GC线程。第一个线程负责回收Heap的Young区。第二个线程在Heap不足时,遍历Heap,将Young区升级为Older区。Older区的大小等于-Xmx减去-Xmn,不能将-Xms的值设的过大,因为第二个线程被迫运行会降低JVM的性能。 
    为什么一些程序频繁发生GC?有如下原因: 
    a、程序内调用了System.gc()或Runtime.gc()。 
    b、一些中间件软件调用自己的GC方法,此时需要设置参数禁止这些GC。 
    c、Java的Heap太小,一般默认的Heap值都很小。 
    d、频繁实例化���象,Release对象。此时尽量保存并重用对象,例如使用StringBuffer()和String()。 
    如果你发现每次GC后,Heap的剩余空间会是总空间的50%,这表示你的Heap处于健康状态。许多Server端的Java程序每次GC后最好能有65%的剩余空间 

    三、JVM如何设置虚拟内存 
    提示:在JVM中如果98%的时间是用于GC且可用的Heap size 不足2%的时候将抛出此异常信息。 
    提示:Heap Size 最大不要超过可用物理内存的80%,一般的要将-Xms和-Xmx选项设置为相同,而-Xmn为1/4的-Xmx值。 
    提示:JVM初始分配的内存由-Xms指定,默认是物理内存的1/64;JVM最大分配的内存由-Xmx指定,默认是物理内存的1/4。默认空余堆内存小于40%时,JVM就会增大堆直到-Xmx的最大限制;空余堆内存大于70%时,JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。 
    提示:假设物理内存无限大的话,JVM内存的最大值跟操作系统有很大的关系。简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制,这个限制一般是2GB-3GB(一般来说Windows系统下为1.5G-2G,Linux系统下为2G-3G),而64bit以上的处理器就不会有限制了 
    提示:注意:如果Xms超过了Xmx值,或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。 
    提示:设置NewSize、MaxNewSize相等,"new"的大小最好不要大于"old"的一半,原因是old区如果不够大会频繁的触发"主" GC ,大大降低了性能 
    提示:增加Heap Size 虽然会降低GC的频率,但也增加了每次GC的时间。并且GC运行时,所有的用户线程将暂停,也就是GC期间,Java应用程序不做任何工作。 
    提示:Heap Size 并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值,因为Java为其他任务分配内存,例如每个线程的Stack等。 
    提示:每个线程都有他自己的Stack,Stack Size 限制着线程的数量。如果Stack过大就好导致内存溢漏。-Xss参数决定Stack大小,例如-Xss1024K。如果Stack太小,也会导致Stack溢漏。 


    JVM使用-XX:PermSize设置非堆内存初始值,默认是物理内存的1/64;由XX:MaxPermSize设置最大非堆内存的大小,默认是物理内存的1/4。 
    解决方法:手动设置Heap size 
    修改TOMCAT_HOME/bin/catalina.bat 
    在"echo "Using CATALINA_BASE: $CATALINA_BASE""上面加入以下行: 
    JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m" 

    四、不健壮代码的特征及解决办法 
    1、尽早释放无用对象的引用。好的办法是使用临时变量的时候,让引用变量在退出活动域后,自动设置为null,暗示垃圾收集器来收集该对象,防止发生内存泄露。对于仍然有指针指向的实例,jvm就不会回收该资源,因为垃圾回收会将值为null的对象作为垃圾,提高GC回收机制效率; 
    2、我们的程序里不可避免大量使用字符串处理,避免使用String,应大量使用StringBuffer,每一个String对象都得独立占用内存一块区域;例如 
    3、尽量少用静态变量,因为静态变量是全局的,GC不会回收的; 
    4、避免集中创建对象尤其是大对象,JVM会突然需要大量内存,这时必然会触发GC优化系统内存环境;显示的声明数组空间,而且申请数量还极大。 
    5、尽量运用对象池技术以提高系统性能;生命周期长的对象拥有生命周期短的对象时容易引发内存泄漏,例如大集合对象拥有大数据量的业务对象的时候,可以考虑分块进行处理,然后解决一块释放一块的策略。 
    6、不要在经常调用的方法中创建对象,尤其是忌讳在循环中创建对象。可以适当的使用hashtable,vector 创建一组对象容器,然后从容器中去取那些对象,而不用每次new之后又丢弃 
    7、一般都是发生在开启大型文件或跟数据库一次拿了太多的数据,造成 Out Of Memory Error 的状况,这时就大概要计算一下数据量的最大值是多少,并且设定所需最小及最大的内存空间值。


    展开全文
  • *内存泄漏和内存溢出

    千次阅读 2017-06-27 14:03:20
    (1)内存泄漏和内存溢出 内存泄漏:分配出去的内存无法回收(不再使用的对象或者变量仍占内存空间),在Java中内存泄漏就是存在一些被分配的对象(可达的,却是无用的)无法被gc回收。 内存溢出:程序要求的内存...
  • 简而言之 右键你的连接=》复制连接=》删除原连接=》修改复制的连接的名字为原连接的名称=》搞定收工
  • 解决 SqlServer执行脚本,SQL文件太大,内存溢出问题,直接编辑文件复制粘贴形式没有任何反应; 执行.sql脚本文件,如果文件较大时,执行会出现内存溢出问题,可用命令替代 cmd 中输入 osql -S 127.0.0.1,1433 -U sa ...
  • django的调试模式功能强大,但是在该模式下,所有的SQL查询都会被保存在内存中,所以项目上线后应该关闭调试模式,避免内存溢出。如果你发现自己的django项目内存占用不断升高,不用慌,可能仅仅是由于开启了调试...
  • MapReduce作业运行过程中内存溢出错误分类 1、 Mapper/Reducer阶段JVM内存溢出(一般都是堆) 1) JVM堆(Heap)内存溢出:堆内存不足时,一般会抛出如下异常: 第一种:“java.lang.OutOfMemoryError:” GC overhead...
  • 深入理解Java虚拟机-Java内存区域与内存溢出异常

    万次阅读 多人点赞 2020-01-03 21:42:24
    Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的"高墙",墙外面的人想进去,墙里面的人却想出来。 文章目录概述运行时数据区域程序计数器(线程私有)Java虚拟机栈(线程私有)局部变量表操作数栈动态链接...
  • 1、传统的在内存中读取 读取文件行的标准方式是在内存中读取,Guava 和Apache Commons IO都提供了如下所示快速... 这种方法带来的问题是文件的所有行都被存放在内存中,当文件足够大时很快就会导致程序抛出OutOfMe.
  • Java内存溢出和内存泄露

    千次阅读 2015-10-08 14:16:41
    1、内存泄露一般是代码设计存在缺陷导致的,通过了解内存泄露的场景,可以避免不必要的内存溢出和提高自己的代码编写水平;   2、通过了解内存溢出的几种常见情况,可以在出现内存溢出的时候快速的
  • 内存溢出

    千次阅读 2010-03-12 14:20:00
    http://baike.baidu.com/view/79183.htm 内存溢出已经是软件开发历史上存在了近40年的“老大难”问题,象在“红色代码”病毒事件中表现...据有关安全小组称,操作系统中超过50%的安全漏洞都是由内存溢出引起的,其中大
  • Java内存区域与内存溢出

    千次阅读 2020-02-09 17:27:55
    在C语言中,开发者需要维护对象的出生和死亡,往往需要为每个new出来的对象编写配套的delete/free代码来释放内存,否则可能发生内存泄漏或溢出。 而在Java中,内存由JVM管理,垃圾回收器GC会帮助开发者自动回收不再...
  • 虽然jvm可以通过GC自动回收无用的内存,但是代码不好的话仍然存在内存溢出的风险。...1、内存泄露一般是代码设计存在缺陷导致的,通过了解内存泄露的场景,可以避免不必要的内存溢出和提高自己的代码
  • C++编程中内存溢出问题

    千次阅读 2015-11-02 18:02:06
    转载自另一篇博客:... 1. 良好的编程习惯是预防内存漏洞的根本 2.  正确申请和释放内存空间。 3.  记得在每个可能的出口检查指针 ...一、为什么会出现内存溢出问题?...导致内存溢出问题的原因有
  • Tomcat内存溢出原因分析

    千次阅读 2016-08-02 12:40:28
    Tomcat内存溢出的原因   在生产环境中tomcat内存设置不好很容易出现内存溢出。造成内存溢出是不一样的,当然处理方式也不一样。  这里根据平时遇到的情况和相关资料进行一个总结。常见的一般会有下面三种情况...
  • java内存区域与内存溢出

    千次阅读 2017-02-24 16:27:56
    内存模型  Java虚拟机在执行java程序的过程中把他所管理的内存划分为若干个不同的数据区域。包括:程序计数器、java虚拟机栈、本地发放栈、java堆、方法区。 内存模型如图:  程序计数器 一块较小...
  • 对于Java开发人员来讲,在虚拟机自动内存管理机制的帮助下,不需要为每一个new操作去写配对的delete/free代码, 不容易出现内存泄露和内存溢出的问题。 正是因为JVM管理内存控制的权利,一旦出现内存泄露和内存溢出...
  • 生产环境JVM内存溢出案例分析

    千次阅读 2019-04-07 21:36:44
    线上JVM内存溢出案例分析详解,本文不仅详细的介绍了生产环境JVM内存溢出的故障分析过程,更是提供在故障发生之前如何快速隔离故障源、防止故障扩散等方法。
  • Java内存区域与内存溢出异常 1.概述 对于 Java 的开发者来说,在虚拟机的自动内存管理机制的帮助下,不再需要为每一个 new 操作去写配对的 delete/ free 代码,这样不容易出现内存泄露和内存溢出的问题,只要...
  • IDEA解决运行项目虚拟内存溢出问题

    万次阅读 2018-07-03 16:23:22
    在我们运行一个比较大的项目的时候总是出现Caused by: java.lang.OutOfMemoryError: PermGen space的问题简单在网上查询了一下意思是内存溢出了,什么?我的电脑是8G运行内存,256的固态,你告诉这样都能内存溢出?...
  • CPU过载内存溢出分析

    千次阅读 2018-04-05 17:34:20
    CPU过载、内存溢出问题一般出现在线上项目中,因为开发环境用户量和数据量都很小,即使你的代码有问题也不会爆发出来。线上出现这样的问题是比较严重的,需要认真对待,妥善解决。问题原因造成这样问题有两个大类型...
  • 定位jvm内存溢出

    千次阅读 2019-04-09 18:08:47
    生产环境JVM内存溢出案例分析 中间件兴趣圈 中间件兴趣圈 微信号dingwpmz_zjj 功能介绍关注后端技术架构、java多线程、并发、Netty、Mycat、Dubbo、ElasticJob、RocketMQ、Elasticsearch等中间件技术。 前天 ...
  • 记一次堆外内存溢出排查过程

    万次阅读 2018-09-30 12:58:14
    服务器发布/重启后,进程占用内存 21%(3g),观察进程占用内存,以一天4%左右的速度增长,一定时间过后,java 进程内存增长到接近 90%,服务器报警。此时 old 区占用 50%,未达到 CMS GC 阈值,因此不会触发 CMS GC,...
  • 关于collector服务内存溢出异常问题

    千次阅读 2017-07-23 14:51:35
    关于内存溢出,java服务异常的分析过程
  • 深入理解Java内存区域与内存溢出异常 前言 Java开发中,我们不需要像在进行C/C++开发那样,需要自己去写delete/free来释放申请的内存,在Java中内存是交给虚拟机管理,凡事都是两面的,因为我们把内存控制权交给...
  • 那么问题来了什么是内存溢出out of memory?(OOM)已有数据超出其分配内存所能存储的范围 比如申请了一个integer,但给它存了long才能存下的数,那就是内存溢出。什么是内存泄露memory leak? 指程序在申请内存后...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 44,105
精华内容 17,642
关键字:

复制文件导致内存溢出