class ReaderThread extends Thread
    {
    InputStream input_stream = null;
    Socket socket = null;
    ByteBuffer readBuffer = new ByteBuffer();
        ByteBuffer line = new ByteBuffer();
        ....

    public void run ()
    {
            ....
            // Читаем посимвольно - набиваем буфер.
            // сюда мы попадаем не для каждого IP адреса
            while( (ch = input_stream.read()) != -1 )
            {
              .... 
              if(конец строки и еще кое что) 
              ....
                // Пеночка №1: чтобы сделать нечто полезное с текстовыми (ASCII)
                // данными их надо в строку widechar загнать. 
                // Не барское это дело с bytes работать.
                // Реаллокация буфера №1 - кол-во байт +2N. 
                   String header_line =  new String( line.get() );

                // Пеночка №2: делаем еще одну строку потому как нам надо 
                // регистронезависимый парсинг делать. 
                // Реаллокация буфера №2 - кол-во байт +2N+2N. 
            header_line = header_line.toUpperCase().substring( 0, len - 2 );

                // Теперь собсвенно вызываем startsWith - для чего и делалась вся
                // бодяга выше.
        if( header_line.startsWith( HttpHeader.HTTP_CONTENT_LENGTH ) )
        {
                    // Щаз будем парсить.
                    // Аллокация объекта - сколько ест - то нам не ведомо. 
            StringTokenizer v = new StringTokenizer(header_line, ": ");

                    // Теперича значить толкаем на стек try frame
                    // потому как нужно ловить NumberFormatException в Integer.parseInt
            try{
            v.nextToken();
                v.nextToken(" ");
                     ContentLen = Integer.parseInt( v.nextToken() );
            }catch(Exception e3){}
        }
              }  
            } 
        }
   }
}

"Наличией высокоуровневых библиотек ... сокращает время разработки, позволяет разрабатывать более сложные системы, меньше выполняя закатов солнца вручную, уменьшает количество ошибок." (с) savaDAN

Этот код, как бы он плох не был, не может вызвать GPF и отказ операционной системы, но вполне может привести к временному DoS (отказ в обслуживании), вызванному исчерпанием свободной памяти при массовых запросах на обслуживание.
(с) iZEN

Вообще то, перенос клиентского кода на сервер ни к чему хорошему не приведет(скорее всего), не важно, на чем и как написан код, дело не в managed/unmanaged, а в совершенно разных требованиях предъявляемых к клиентскому м серверному коду.
(С) Nickolay Ch.

V>Как я с Вами согласен.

V>

    // Щаз, пацаны, мы покажем как писать надежный метод надежной библиотеки. 
    // Вот типа шоб враги, значить, нашу унутренню  minSize (типа Dimension) 
    // грязными руками (омытыми водами Ганга), значить, не похакали мы ея
    // типа скопируем шоб, значить, не напрягать мозг созданием 
    // immutable Dimension класса. Ну типа он же у нас уже есть, фигли тада напрягаться?

    public synchronized Dimension getPreferredSize(int rows, int cols) {
    return new Dimension(minSize);
    }

    // "AWT есть но не работает!"
    // "Та що ви говорите? От дасада... А зато душа в ней гарна, сил нет..."
    // ...
    // "Не... в то место моя щира душа не поместится...."

class ReaderThread extends Thread {
  public void run ()
  {
  }
}

CS>class ReaderThread extends Thread {
CS>  public void run ()
CS>  {
CS>  }
CS>}
      
CS>

Threading Guidelines
This section discusses guidelines that you can use to help improve threading
efficiency in ASP.NET. The guidelines include the following:
— Tune the thread pool by using the formula to reduce contention.
— Consider minIoThreads and minWorkerThreads for burst load.
— Do not create threads on a per-request basis.
— Avoid blocking threads.

Только вот код, который ты показал — это типичный метод программирования в управляемых средах.

CS> Влад, я уже этот форум читаю года четыре. И вот это твой оптимизм "подождем светлого будущего..."

Выделение памяти в стеке
C++ дает программистам выбор между размещением объектов в куче или в стеке. Размещение в стеке эффективнее: выделение памяти дешевле, освобождение совсем ничего не стоит, а язык предоставляет поддержку при разметке сроков жизни объектов, снижая риск забыть освободить объект. С другой стороны, в C++ нужно быть очень внимательным при публикации или совместном использовании ссылок на размещенные в стеке объекты, поскольку они автоматически освобождаются при раскрутке фрейма стека, что приводит к появлению "висячих" указателей.
Еще одно достоинство размещения в стеке состоит в том, что оно куда лучше работает с кешем. На современных процессорах стоимость промаха мимо кеша весьма существенна, так что если язык и runtime могут помочь программе достичь лучшей локальности данных, производительность также повысится. Вершина стека в кеше практически всегда "горячая", а вершина кучи – "холодная" (поскольку с момента последнего использования памяти, скорее всего, прошло немало времени). В результате размещение объекта в куче скорее приведет к большему числу промахов мимо Кеша, чем размещение объекта в стеке.
Что еще хуже, промах мимо кеша при размещении объекта в куче приводит к весьма грязной работе с памятью. При выделении памяти из кучи содержание этой памяти является мусором – битами, оставшимися с момента последнего использования памяти. При выделении не хранящегося в кеше блока памяти из кучи, исполнение приостановится на время переноса содержимого этой памяти в кеш. Затем эти значения будут немедленно переписаны нулями или другими исходными значениями. Все это вместе означает большой объем напрасной работы с памятью (некоторые процессоры, например, Azul Vega, аппаратно ускоряют выделение памяти из кучи).
Escape-анализ
Язык Java не предлагает никакого способа явно разместить объект в стеке, но это не мешает JVM при случае использовать размещение в стеке. JVM могут использовать технику, именуемую escape-анализом (escape analysis), который может определить, что определенные объекты остаются прикованными к определенному потоку на весь срок жизни, и что этот срок жизни ограничен сроком жизни данного фрейма стека. Такие объекты можно безопасно размещать в стеке вместо кучи. Даже лучше, в случае мелких объектов, JVM может полностью избавиться от выделения памяти и просто размещать поля объектов в регистрах.
Листинг 2 показывает пример применения escape-анализа. Метод Component.getLocation() создает защитную копию поля location, так что вызывающая сторона не может случайно изменить текущее расположение компонента. Вызов getDistanceFrom() сперва получает местоположение другого компонента (что включает создание объекта), а затем использует поля x и y объекта, возвращаемого getLocation(), для вычисления расстояния между двумя экземплярами компонентов.
Листинг 2.

public class Point 
{
  private int x, y;

  public Point(int x, int y) 
  {
    this.x = x; this.y = y;
  }

  public Point(Point p) { this(p.x, p.y); }
  public int getX() { return x; }
  public int getY() { return y; }
  public void setX(int newValue) { x = newValue; }
  public void setY(int newValue) { y = newValue; }
}

public class Component 
{
  private Point location;

  public Point getLocation() { return new Point(location); }

  public double getDistanceFrom(Component other) 
  {
    Point otherLocation = other.getLocation();
    int deltaX = otherLocation.getX() - location.getX();
    int deltaY = otherLocation.getY() - location.getY();

    return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
  }
}

Метод getLocation() не знает, что вызывающая сторона собирается делать с возвращаемым им Point; она может удерживать ссылку на него, например, поместив ее в коллекцию, так что getLocation() написан в безопасной манере. Но в этом примере getDistanceFrom() не собирается модифицировать получаемые объекты или запоминать ссылки на них. Он просто собирается ненадолго задействовать Point, а затем избавиться от него, что в данном случае выглядит как разбазаривание ресурсов.
Хорошая JVM может разобраться в происходящем и избавиться от размещения защитной копии. Сначала вместо вызова getLocation() будет подставлено (inlined) тело этого метода, то же будет сделано с вызовами getX() и getY(), в результате чего getDistanceFrom() станет выглядеть так, как показано в листинге 3.
Листинг 3.

public double getDistanceFrom(Component other) 
{
  Point otherLocation = new Point(other.x, other.y);
  int deltaX = otherLocation.x - location.x;
  int deltaY = otherLocation.y - location.y;

  return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}

Здесь escape-анализ может показать, что объект, создаваемый в первой строке, никогда не покинет своего базового блока и что getDistanceFrom() никогда не изменяет состояние компонента other (под "покинет" имеется в виду то, что ссылка на него не хранится в куче и не передается неизвестному коду, который может удерживать копию). При том, что Point действительно используется только в одном потоке и его время жизни, как известно, ограничено базовым блоком, в котором он размещен, он может быть либо размещен в стеке, либо полностью соптимизирован, как показано в листинге 4.
Листинг 4.

public double getDistanceFrom(Component other) 
{
  int tempX = other.x, tempY = other.y;
  int deltaX = tempX - location.x;
  int deltaY = tempY - location.y;
  return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}

В результате мы получаем точно такую же производительность, как если бы все поля были публичными, но с сохранением безопасности, предоставляемой инкапсуляцией и защитным копированием (и остальными техниками безопасного программирования).
Escape-анализ в Mustang
Escape-анализ – это оптимизация, о которой говорилось уже давно, и вот, наконец, она здесь – текущие версии Mustang (Java SE 6) могут выполнять escape-анализ и конвертировать выделение памяти в куче в выделение памяти в стеке (или просто избавляться от выделения памяти) там, где это возможно. Использование escape-анализа для устранения некоторых распределений памяти приводит к еще большему ускорению работы с памятью, снижению расхода памяти и уменьшению количества промахов мимо кеша. Кроме того, это снижает нагрузку на сборщик мусора и позволяет реже производить сборку.
Заключение
JVM удивительно хорошо делают вещи, которые раньше были полностью отданы на откуп разработчику. Позволяя JVM выбирать между выделением памяти в куче и в стеке, можно получить преимущества производительности выделения памяти в стеке, не заставляя программиста мучаться с выбором.

Brian Goetz

runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management.

public class Component 
{
  private Point location;

  public const Point getLocation() { return location; }

  public double getDistanceFrom(const Component other) 
  {
    const Point otherLocation = other.getLocation();
    int deltaX = otherLocation.getX() - location.getX();
    int deltaY = otherLocation.getY() - location.getY();

    return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
  }
}

public synchronized Dimension getPreferredSize(int rows, int cols) 
{
  return new Dimension(minSize);
}

С другой стороны смею вас заверить, память отлично течет и системах с GC (особенно этим грешит VB6), но багов из за этого на порядок меньше, и искать и исправлять их тоже значительно проще.

class Some_Actor
    {
    private :
        //! Указатели на потоки, которые реально будут использоваться.
        std::istream * in_;
        std::ostream * out_;
        //! Потоки, на случай работы с файлами, а не со стандартным вводом/выводом.
        std::ifstream file_in_;
        std::ofstream file_out_;
        
    public :
        Some_Actor()
            // По умолчанию будем работать со стандартным вводом/выводом.
            :    in_( &std::cin )
            ,    out_( &std::cout )
            {}
            
        // Стартовать работу. Если какой-то из указателей не равен 0, то вместо
        // соответствующего потока нужно использовать указанный файл.
        void start( const char * in_file_name, const char * out_file_name )
            {
                if( in_file_name )
                    {
                        file_in_.open( in_file_name );
                        in_ = &file_in_;
                    }
                if( out_file_name )
                    {
                        file_out_.open( out_file_name );
                        out_ = &file_out_;
                    }
                ...
            }
        ...
    };

E>>Так что, имхо, сменили шило на мыло

using(Stream myStream = new FileInfo("...").OpenRead())
{
  using (StreamReader sr = new StreamReader(myStream)
    {
      ...
    }
}

using(TextReader tr = GetReader())
{
  ...
} // здесь будет закрыт и поток. 

private TextReader GetReader()
{
  return new StreamReader(new FileStream("..."));
}

private Image GetImage()
{
  return Image.FromStream(new FileStream("myimg.gif"));
}

// Вот как приходится делать:
private Image SafeGetImage()
{
  using(Stream imgStream = new FileStream("myimg.gif"))
    {
      byte[] buf = new byte[imgStream.Length];
        imgStream.Read(buf, 0, buf.Length);
        return Image.FromStream(new MemoryStream(buf));
    }
}

1.1.4 stable rev. 510

f = File.new( "myfile.txt" )
f.gets ... # какая-то обработка.
# Упс! Забыли f.close вызвать.

File.open( "myfile.txt" ) { |f| f.gets ... }

def File.open(file_name)
    f = File.new(file_name)
    if block_given? # Если передали в функцию блок кода...
        begin # аналог try
            yeild f # вызываем этот блок...
        ensure # аналог finally
            f.close
        end
        return nil
    else
        return f
    end
end

b[ key ] = a[ key ]

b[ key ] = a[ key ].clone

VD>Куда ж более то?

#include <fstream>
#include <iostream>
#include <string>
#include <stdexcept>

void do_test()
    {
        const std::string file_name( "test.txt" );
        const std::string content( "Hello, world!" );

        // Пресоздаем файл для записи.
        std::ofstream out_file( file_name.c_str(), std::ios::out | std::ios::trunc );

        // И открываем его тут же для чтения.
        std::ifstream in_file( file_name.c_str(), std::ios::in );

        // Размер файла, открытого на чтение равен 0.
        in_file.seekg( 0, std::ios::end );
        if( 0 != in_file.tellg() )
            throw std::runtime_error( "EOF in in_file expexted!" );

        // Записываем в выходной файл строку...
        out_file << content << std::flush;

        // И считываем ее в том же виде из входного файла.
        std::string in_line;
        std::getline( in_file, in_line );

        // Должна получиться та же самая строка.
        if( content != in_line )
            throw std::runtime_error( "expected value: " + content +
                    ", actual value: " + in_line );
    }

int main()
    {
        try
            {
                do_test();
            }
        catch( const std::exception & x )
            {
                std::cerr << "Oops! " << x.what() << std::endl;
            }
    }

E>>f = File.new( "myfile.txt" )
E>>f.gets ... # какая-то обработка.
E>># Упс! Забыли f.close вызвать.
E>>

E>>File.open( "myfile.txt" ) { |f| f.gets ... }
E>>

...
E>>