在一次偶然的应程序开发过程中，发现一个很奇怪的问题。大概现象为，一个很简单的程序逻辑，开启了几个线程，程序本身并没有过多的申请内存，或者说根本没有申请内存，但是在实际运行起来后，通过PS命令和status 查看内存占用居然达到了40M，详细分析了smaps文件没有得到实际的分析结果。突然想到有可能是线程导致了进程的内存增加，于是便开始了测试代码的编写，测试代码如下:
/* test_thread.c */
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <pthread.h>
#include <sys/types.h>
//#include <limit.h>
/* 测试第一个线程 */
void * test_thread(void * pParam)
{
    while(1)
    {
        sleep(1);
    }
    return (void*)0;
}
int main(int argc , char ** argv)
{
    /* 启动一个线程 */
    pthread_t thread_id = 0;
    pthread_create(&thread_id,0,test_thread,0);
    while(1)
    {
        sleep(1);
    }
    return 0;
}
[oracle@localhost test_thread]$ gcc test_thread.c -lpthread
[oracle@localhost test_thread]$ ls
a.out  test_thread.c
[oracle@localhost test_thread]$ ./a.out
一个简单的多线程测试程序，该进程开启了两个线程，一个主线程，一个子线程。通过:
[oracle@localhost test_thread]$ ps -aux | grep a.out
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
oracle   22725  0.0  0.0  12320   428 pts/0    Sl+  21:47   0:00 ./a.out
oracle   22744  0.0  0.0   5952   748 pts/1    S+   21:47   0:00 grep a.out

得到一个简单的多线程程序居然占了10MB内存之多，于是想到了多线程的线程栈空间问题，虽然多线程在运行时是共享内存空间的，但是各个线程之间的栈区还是是相对独立的，是不是在启动线程时，操作系统默认给子线程分配了过多的内存？二话不说，开始测试:
void get_thread_stacksize()
{
    pthread_attr_t pattr;
    int status = 0;
    size_t size = 0;
    //printf("default size:%d\n", size);
    status = pthread_attr_getstacksize(&pattr, &size);
    if(0 != status)
    {
        printf("pthread_attr_getstacksize err [%d]\n",status);
        return -1;
    }
    printf("current thread stack size:%d\n", size);
    return 0;
}

输出:
[oracle@localhost test_thread]$ ./a.out 
current thread stack size:10485760

通过换算，刚好10MB，可见Linux默认情况下启动一个子线程需要分配10MB的线程栈空间，为了降低进程内存占用，就必须将该默认值修改，在Windows下该默认值一般为1MB，通过修改编译选项可以修改，在Linux中可以通过pthread_attr_getstacksize函数修改pthread_attr_t结构后，将pthread_attr_t结构传入pthread_create函数以修改线程默认栈大小。相关代码如下:
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <pthread.h>
#include <sys/types.h>
//#include <limit.h>
/* 测试第一个线程 */
void * test_thread(void * pParam)
{
    while(1)
    {
        sleep(1);
    }
    return (void*)0;
}
void get_thread_stacksize_for_attr(pthread_attr_t * p_pattr)
{
    int status = 0;
    size_t size = 0;
    //printf("default size:%d\n", size);
    status = pthread_attr_getstacksize(p_pattr, &size);
    if(0 != status)
    {
        printf("pthread_attr_getstacksize err [%d]\n",status);
        return -1;
    }
    printf("current thread stack size:%d\n", size);
    return 0;
}
void get_thread_stacksize()
{
    pthread_attr_t pattr;
    int status = 0;
    size_t size = 0;
    //printf("default size:%d\n", size);
    status = pthread_attr_getstacksize(&pattr, &size);
    if(0 != status)
    {
        printf("pthread_attr_getstacksize err [%d]\n",status);
        return -1;
    }
    printf("current thread stack size:%d\n", size);
    return 0;
}
void set_thread_stacksize(pthread_attr_t * p_pthread_attr_t,size_t size)
{
    //pthread_attr_t pattr;
    int status = 0;
    //printf("default size:%d\n", size);
    status = pthread_attr_setstacksize(p_pthread_attr_t, size);
    if(0 != status)
    {
        printf("pthread_attr_getstacksize err [%d]\n",status);
        return -1;
    }
    printf("set thread stack size:%d\n", size);
    return 0;
}
int main(int argc , char ** argv)
{
    /* 启动一个线程 */
    pthread_t thread_id = 0;
    pthread_attr_t pattr;
    pthread_attr_init(&pattr);
    /* 设置线程栈大小为1M */
    set_thread_stacksize(&pattr,1024*1024);
    //get_thread_stacksize();
    get_thread_stacksize_for_attr(&pattr);
    pthread_create(&thread_id,&pattr,test_thread,0);
    get_thread_stacksize();
    while(1)
    {
        sleep(1);
    }
    return 0;
}
[oracle@localhost test_thread]$ gcc *.c -lpthread
test_thread.c: 在函数‘get_thread_stacksize_for_attr’中:
test_thread.c:26: 警告：在无返回值的函数中，‘return’带返回值
test_thread.c:29: 警告：在无返回值的函数中，‘return’带返回值
test_thread.c: 在函数‘get_thread_stacksize’中:
test_thread.c:41: 警告：在无返回值的函数中，‘return’带返回值
test_thread.c:44: 警告：在无返回值的函数中，‘return’带返回值
test_thread.c: 在函数‘set_thread_stacksize’中:
test_thread.c:55: 警告：在无返回值的函数中，‘return’带返回值
test_thread.c:58: 警告：在无返回值的函数中，‘return’带返回值
[oracle@localhost test_thread]$ 
[oracle@localhost test_thread]$ 
[oracle@localhost test_thread]$ 
[oracle@localhost test_thread]$ 
[oracle@localhost test_thread]$ ./a.out 
set thread stack size:1048576
current thread stack size:1048576
current thread stack size:10485760


oracle    3631  0.0  0.0   5952   748 pts/1    S+   22:26   0:00 grep ./a.out
[oracle@localhost test_thread]$ ps -aux | grep ./a.out
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
oracle    3664  0.0  0.0   3108   508 pts/0    Sl+  22:27   0:00 ./a.out
oracle    3669  0.0  0.0   5952   776 pts/1    S+   22:27   0:00 grep ./a.out

通过测试，修改线程堆栈大小后有效的更改了启动线程时对内存空间的要求。
扩展:
1、  获取Linux默认线程栈大小
Ulimite –s
2、  修改Linux默认线程栈大小
Ulimite –s value

文章目录
1 问题描述
2 测试原理
3 测试数据
4 测试结论
附1：测试代码
附2：一些测试图片

1 问题描述
今天讨论的时候，有人提出了这个的一个观点：多线程会占用大量的内存。
事实上，前操作系统已经发展了半个多世纪，对多线程的调度已经达到了极高的效率，对CPU资源和内存资源的占用已经完全可以忽略。
下面让我们通过一个测试来理解这个结论。
2 测试原理
在Windows操作系统下，启动10万个线程，比较前后内存的占用量，以计算出每个线程的内存占用情况。
这里有几点注意：
本测试结果不应该受语言影响，因为线程的调度是由操作系统完成的，所以本测试的结论是基于操作系统的；
每个线程中不包括任何多余数据，所以最终结论仅应该是每个线程占用内在的情况，而与线程中的数据无关；
3 测试数据
根据附件的图片显示，可以得出以下内容：
启动10万个线程前	0.06%	44,736

启动10万个线程后	0.42%	584,816

注：工作集即是内存实际战胜情况。
4 测试结论
通过这个数据，我们可以得出这个的结论：
每个线程占用的内存约为：(584,816 - 44,736)/10000 = 540KB.
在Linux下测试结论的值为每个线程占用220KB（注：由于测试机器内存小只测试了1万个线程）。
附1：测试代码
import java.util.concurrent.TimeUnit;
 
public class ThreadUsage implements Runnable {
 
    public static void main(String[] args) throws Exception {
        // 等待30秒，以方便截取当前程序占用的硬件资源信息
        TimeUnit.SECONDS.sleep(30);
 
        // 启动10万个线程
        for (int i = 0; i < 10000; i++) {
             new Thread(new ThreadUsage()).start();
        }
    }
 
    // 每个线程做的事情就是等待。
    @Override
    public void run() {
        while (true) {
            try {
                TimeUnit.SECONDS.sleep(1);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

附2：一些测试图片

分析java 线程占用内存

 本文将为您提供一个教程，使您可以确定活动应用程序Java线程中保留了多少Java堆空间 。 将提供来自Oracle Weblogic 10.0生产环境的真实案例研究，以使您更好地理解分析过程。 
 我们还将尝试证明过多的垃圾回收或Java堆空间的内存占用问题通常不是由真正的内存泄漏引起的，而是由线程执行模式和大量的短期对象引起的。 


背景
 正如您从我过去的JVM概述文章中可能已经看到的那样，Java线程是JVM基础的一部分。 您的Java堆空间内存占用量不仅受静态对象和寿命长的对象的驱动，还受寿命短的对象的驱动。 
 通常会错误地认为OutOfMemoryError问题是由于内存泄漏引起的。 我们经常忽略错误的线程执行模式以及它们在Java堆上“保留”到执行完成的短暂对象。 在这种有问题的情况下： 

 您的“预期”应用程序的短期/无状态对象（XML，JSON数据有效载荷等）被线程保留的时间过长（线程锁争用，巨大的数据有效载荷，来自远程系统的响应时间慢等）。 
 最终，这样的短期对象被垃圾收集器提升为长期对象空间，例如OldGen / tenured空间 
 副作用是，这导致OldGen空间快速填充，从而增加了Full GC（主要集合）的频率 
 根据情况的严重性，这可能导致过度的GC垃圾收集，JVM暂停时间增加，并最终导致OutOfMemoryError：Java堆空间 
 您的应用程序现在关闭，您现在对正在发生的事情感到困惑 
 最后，您正在考虑增加Java堆或查找内存泄漏……您是否真的走对了？ 

 在上述情况下，您需要查看线程执行模式并确定每个线程在给定时间保留多少内存。 
好了，我得到了图片，但是线程堆栈的大小呢？
 避免线程堆栈大小和Java内存保留之间的混淆非常重要。 线程堆栈大小是JVM用于存储每个方法调用的特殊内存空间。 当线程调用方法A时，它将调用“推”到堆栈上。 如果方法A调用方法B，它也会被压入堆栈。 方法执行完成后，调用将“弹出”堆栈。 
 由于此类线程方法调用而创建的Java对象在Java堆空间上分配。 增大线程堆栈大小绝对不会有任何效果。 处理java.lang.stackoverflowerror或OutOfMemoryError：无法创建新的本机线程问题时，通常需要调整线程堆栈的大小。 
  
案例研究和问题背景
 以下分析是基于我们最近调查的一个实际生产问题。 

 在用户Web界面进行了一些更改（使用Google Web Toolkit和JSON作为数据有效负载）之后，从Weblogic 10.0生产环境中观察到严重的性能下降。 
 初步分析确实发现了OutOfMemoryError的几种情况：Java堆空间错误以及过多的垃圾回收。 在发生OOM事件后，会自动生成Java堆转储文件（-XX：+ HeapDumpOnOutOfMemoryError） 
 对verbose：gc日志的分析确实确认了32位HotSpot JVM OldGen空间（1 GB容量）的完全耗尽 
 在问题发生之前和期间，也会生成线程转储快照 
 当时唯一可以解决的问题是观察到问题时重新启动受影响的Weblogic服务器 
 最终对变更进行了回滚，这确实解决了这种情况 

 团队首先从引入的新代码中怀疑了内存泄漏问题。 
线程转储分析：寻找可疑对象…


 我们所做的第一步是对生成的线程转储数据进行分析。 线程转储通常会向您显示在Java堆上分配内存的罪魁祸首线程。 它还将揭示试图从远程系统发送和接收数据有效载荷的任何占用线程或阻塞线程。 
 我们注意到的第一个模式是从Weblogic托管服务器（JVM进程）观察到的OOM事件和STUCK线程之间具有良好的相关性。 在找到的主线程模式下面找到： 
<10-Dec-2012 1:27:59 o'clock PM EST> <Error> <BEA-000337>

<[STUCK] ExecuteThread: '22' for queue:

'weblogic.kernel.Default (self-tuning)'

has been busy for '672' seconds working on the request

which is more than the configured time of '600' seconds.
  
 如您所见，以上线程似乎是STUCK或花费很长时间读取和接收来自远程服务器的JSON响应。 一旦找到该模式，下一步就是将该发现与JVM堆转储分析相关联，并确定这些卡住的线程从Java堆中占用了多少内存。 
堆转储分析：保留的对象暴露在外！


 Java堆转储分析是使用MAT执行的。 现在，我们将列出不同的分析步骤，这些步骤确实使我们可以查明保留的内存大小和源。 
 1.加载HotSpot JVM堆转储 


  
 2.选择HISTOGRAM视图并按“ ExecuteThread”进行过滤 


 * ExecuteThread是Weblogic内核用于线程创建和执行的Java类* 
  
 如您所见，这种观点非常明显。 我们可以看到总共创建了210个Weblogic线程。 这些线程保留的内存总量为806 MB。 这对于具有1 GB OldGen空间的32位JVM进程而言非常重要。 仅此观点就告诉我们问题的核心和内存保留源于线程本身。 
 3.深入研究线程内存占用量分析 


 下一步是深入研究线程内存保留。 为此，只需右键单击ExecuteThread类，然后选择：列出对象>具有传出引用。 
  
 如您所见，我们能够将线程转储分析中的STUCK线程与堆转储分析中的高内存保留量相关联。 这一发现非常令人惊讶。 
 4.线程Java局部变量识别 


 最后的分析步骤确实需要我们扩展一些线程样本，并了解内存保留的主要来源。 
  
 如您所见，此最后的分析步骤确实从根本原因上揭示了巨大的JSON响应数据有效载荷。 该模式还通过线程转储分析在早期公开，我们发现一些线程需要很长时间才能读取和接收JSON响应。 数据有效负载占用量巨大的明显症状。 
 至关重要的是要注意，通过局部方法变量创建的短期对象将显示在堆转储分析中。 但是，其中一些将仅在其父线程中可见，因为这种情况下其他对象未引用它们。 您还需要分析线程堆栈跟踪以识别真正的调用者，然后进行代码检查以确认根本原因。 
 根据这一发现，在某些情况下，我们的交付团队能够确定最近的JSON错误代码更改正在生成高达45 MB +的巨大JSON数据有效负载。 考虑到该环境正在使用只有1 GB OldGen空间的32位JVM，您可以理解只有几个线程足以触发严重的性能下降。 
 该案例研究清楚地表明了适当的容量规划和Java堆分析的重要性，包括从活动应用程序和Java EE容器线程中保留的内存。 
其他一切都只是信息


 我希望本文能帮助您了解如何结合线程转储和堆转储分析来确定活动线程保留的Java堆内存占用量。 现在，如果您不尝试的话，本文将仅停留在文字上，因此，我强烈建议您花一些时间自己学习针对您的应用程序进行的分析过程。 

 参考： Java Thread：保留了我们的JCG合作伙伴 Pierre-Hugues Charbonneau在Java EE支持模式和Java教程博客上进行的内存分析 。 
翻译自: https://www.javacodegeeks.com/2012/12/java-thread-retained-memory-analysis.html
分析java 线程占用内存

C#中线程占用内存过大解决方法




项目中用到了多线程,而且是1000线程并发运行,发现内存占用过高,于是对项目里用到的对象逐个测试,发现是线程对象占用内存


            Thread[] threads = new Thread[1000];
            for(int i = 0; i<threads.Length; i++)
            {
                (threads[i] = new Thread(new ThreadStart(delegate()
                { 
                    Thread.Sleep(100000);
                })) { IsBackground = true }).Start();
            };


运行以上测试代码,内存使用量瞬间增加1G, 如果数量写到2000+, 直接抛出System.OutOfMemoryException的异常.
---------------------
经查出thread构造函数里有一个 int maxStackSize, //设置线程最大栈空间
再次测试在构造函数中把 maxStackSize设置为1024, 分配5000线程并发运行, 这次只占用了1.3G左右内存
(事实设置1024实际栈空间并非1024,而是线程自动设置为最小栈空间(测试在200K至400K之间),具体没查这个最小栈空间是多大)
在一般文章中很少见有这个参数被提起.