StringBuffer, и как тяжело избавиться от наследия старого кода02.06.2017 12:03

Комментарии (7)

  • 2 июня 2017 в 10:40

    +1

    ↑

    ↓

    А есть где-нибудь более подробный разбор, что за 10к и 35к объектов создаются при запуске Hello World на пару строк?

    • 2 июня 2017 в 10:57 (комментарий был изменён)

      0

      ↑

      ↓

      Статьи не встречал, но вот что показывает jmap:
      Много классов
      num #instances #bytes class name
      ----------------------------------------------
      1: 402 4903520 [I
      2: 1621 158344 [C
      3: 455 52056 java.lang.Class
      4: 194 49728 [B
      5: 1263 30312 java.lang.String
      6: 515 26088 [Ljava.lang.Object;
      7: 115 8280 java.lang.reflect.Field
      8: 258 4128 java.lang.Integer
      9: 94 3760 java.lang.ref.SoftReference
      10: 116 3712 java.util.Hashtable$Entry
      11: 126 3024 java.lang.StringBuilder
      12: 8 3008 java.lang.Thread
      13: 74 2576 [Ljava.lang.String;
      14: 61 1952 java.io.File
      15: 38 1824 sun.util.locale.LocaleObjectCache$CacheEntry
      16: 12 1760 [Ljava.util.Hashtable$Entry;
      17: 53 1696 java.util.concurrent.ConcurrentHashMap$Node
      18: 23 1472 java.net.URL
      19: 14 1120 [S
      20: 2 1064 [Ljava.lang.invoke.MethodHandle;
      21: 1 1040 [Ljava.lang.Integer;
      22: 26 1040 java.io.ObjectStreamField
      23: 12 1024 [Ljava.util.HashMap$Node;
      24: 30 960 java.util.HashMap$Node
      25: 20 800 sun.util.locale.BaseLocale$Key
      26: 15 720 java.util.HashMap
      27: 18 720 java.util.LinkedHashMap$Entry
      28: 12 672 java.lang.Class$ReflectionData
      29: 40 640 java.lang.Object
      30: 19 608 java.util.Locale
      31: 19 608 sun.util.locale.BaseLocale
      32: 9 560 [Ljava.lang.reflect.Field;
      33: 10 560 sun.misc.URLClassPath$JarLoader
      34: 5 528 [Ljava.util.concurrent.ConcurrentHashMap$Node;
      35: 21 504 java.net.Parts
      36: 21 504 sun.security.action.GetPropertyAction
      37: 6 480 java.lang.reflect.Constructor
      38: 12 480 java.security.AccessControlContext
      39: 20 480 java.util.Locale$LocaleKey
      40: 18 432 java.io.ExpiringCache$Entry
      41: 1 384 java.lang.ref.Finalizer$FinalizerThread
      42: 6 384 java.nio.DirectByteBuffer
      43: 6 384 java.util.concurrent.ConcurrentHashMap
      44: 1 376 java.lang.ref.Reference$ReferenceHandler
      45: 14 336 java.lang.StringBuffer
      46: 6 336 java.nio.DirectLongBufferU
      47: 10 320 java.lang.OutOfMemoryError
      48: 10 288 [Ljava.io.ObjectStreamField;
      49: 7 280 java.lang.ref.Finalizer
      50: 11 264 sun.misc.URLClassPath$3
      51: 14 256 [Ljava.lang.Class;
      52: 3 240 [Ljava.util.WeakHashMap$Entry;
      53: 10 240 sun.misc.MetaIndex
      54: 7 224 java.lang.ref.ReferenceQueue
      55: 7 224 java.util.Vector
      56: 5 200 java.util.WeakHashMap$Entry
      57: 6 192 java.io.FileDescriptor
      58: 4 192 java.nio.HeapCharBuffer
      59: 4 192 java.util.Hashtable
      60: 2 176 java.lang.reflect.Method
      61: 7 168 java.util.ArrayList
      62: 3 168 sun.nio.cs.UTF_8$Encoder
      63: 9 144 java.lang.ref.ReferenceQueue$Lock
      64: 3 144 java.nio.HeapByteBuffer
      65: 3 144 java.util.WeakHashMap
      66: 6 144 sun.misc.PerfCounter
      67: 2 128 java.io.ExpiringCache$1
      68: 3 120 java.security.ProtectionDomain
      69: 1 104 sun.net.www.protocol.file.FileURLConnection
      70: 3 96 java.io.FileInputStream
      71: 3 96 java.io.FileOutputStream
      72: 2 96 java.lang.ThreadGroup
      73: 3 96 java.security.CodeSource
      74: 2 96 java.util.Properties
      75: 3 96 java.util.Stack
      76: 2 96 java.util.StringTokenizer
      77: 1 96 sun.misc.Launcher$AppClassLoader
      78: 2 96 sun.misc.URLClassPath
      79: 2 96 sun.nio.cs.StreamEncoder
      80: 4 96 sun.usagetracker.UsageTrackerClient$1
      81: 1 88 sun.misc.Launcher$ExtClassLoader
      82: 1 80 [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;
      83: 2 80 [Ljava.net.URL;
      84: 2 80 java.io.BufferedWriter
      85: 2 80 java.io.ExpiringCache
      86: 5 80 java.lang.Class$3
      87: 2 80 sun.nio.cs.UTF_8$Decoder
      88: 3 72 [Ljava.lang.reflect.Constructor;
      89: 3 72 java.lang.Class$1
      90: 3 72 java.lang.RuntimePermission
      91: 3 72 java.util.Collections$SynchronizedSet
      92: 3 72 java.util.concurrent.atomic.AtomicLong
      93: 3 72 sun.misc.Signal
      94: 3 72 sun.reflect.NativeConstructorAccessorImpl
      95: 2 64 [Ljava.lang.Thread;
      96: 2 64 java.io.FilePermission
      97: 2 64 java.io.PrintStream
      98: 2 64 java.lang.ClassValue$Entry
      99: 2 64 java.lang.NoSuchMethodError
      100: 2 64 java.lang.ThreadLocal$ThreadLocalMap$Entry
      101: 2 64 java.lang.VirtualMachineError
      102: 2 64 java.lang.ref.ReferenceQueue$Null
      103: 1 48 [J
      104: 2 48 [Ljava.io.File;
      105: 2 48 [Ljava.lang.reflect.Method;
      106: 3 48 [Ljava.security.Principal;
      107: 2 48 java.io.BufferedOutputStream


  • 2 июня 2017 в 11:12

    0

    ↑

    ↓

    интересно было бы сравнить насколько ускорится тестовая программа на JDK8 и JDK9, где JDK-8041679 уже поправлен. Понятно, что в 9ке есть не только эти изменения и оптимизации, поэтому чистого сравнения не получится. В Java делали оптимизации и в synchronized блоке и сейчас он работает быстрее, чем, допустим, в JDK 1.4.

    • 2 июня 2017 в 11:18

      0

      ↑

      ↓

      В Java делали оптимизации и в synchronized блоке и сейчас он работает быстрее, чем, допустим, в JDK 1.4.

      Да, компилятор может удалять sync блоки, если может доказать что они не нужны. Но не факт, что это сработает/срабатывает именно на старте JVM.

  • 2 июня 2017 в 11:12

    0

    ↑

    ↓

    Откуда берутся объекты понятно, просто запихнуть переменные среды в System и вот вам уже ~200 штук. А по syncronized проблема не проблема, т.к. если я правильно помню, то jvm делает ни к чему не обязывающий biased lock. Насколько здесь деградирует производительность мне сложно сказать, но не думаю, что будет сильно заметно. Резюмируя, не в обиду, проблемы кажутся высосанными из пальца

    • 2 июня 2017 в 11:20 (комментарий был изменён)

      +1

      ↑

      ↓

      Конечно, проблемы особой нету. Но sync это больше байткода, больше работы для JVM как ни крути. Пусть и речь о наносекундах. В общем случае — чем проще и меньше кода, тем лучше. Тем более когда эти sync блоки вообще не несут никакой пользы.

    • 2 июня 2017 в 11:59

      +1

      ↑

      ↓

      просто никому не нравится legacy)

© Habrahabr.ru