Using heap viewer, we can see that after
the first GC, only 1.39 megs is free.
This may indicate that the garbage
collector wasn't able to reclaim much
memory due to a leak.
After a second GC event, heap viewer
indicates that the system has decided to
accommodate a larger memory footprint
for this app by allocating more memory.
Increasing the heap
size to 32 megabytes,
which is up from 20
megabytes in the first GC.
This time,
we have 12.9 megabytes free in our heap.
At this point, the system is
dynamically accommodating for
the larger memory footprint of this app.
If the expansion repeats, this may lead
to an app crash if the system can no
longer allocate more memory for the app.
So remember, memory leaks are slow and
they're insidious and require time and
the proper test environment to confirm.
Also, keep in mind that
sometimes a pattern like this
might represent
a legitimate use of memory.
For example,
imagine an application that was designed
to manipulate large graphics or photos.
The takeaway here is be on the lookout
for slow leaking memory, but
always weigh the data you collect,
against the memory implications
of your app's core functionality.
Now at this point, you should understand
how memory leaks manifest in the SD.
At this point, you should understand how
memory leaks manifest in SDK provided
tools such as Memory Monitor and
Heap Viewer.
But you might not know
where they originate.
Here are some best practices
you can take to avoid a leak.
Track the life of your objects
throughout your code and
clean up references when
you no longer need them.
Okay, so in the next slide,
we'll identify what might
be causing this leak.
بعد عارض الذاكرة التكويمية GC الأولى،
يوجد فقط 1.39 ميجا فارغة.
قد يشير هذا إلى أن جامع البيانات
عديمة النفع لم يستطع استعادة كثير
من الذاكرة بسبب التسريب.
بعد حدث GC الثاني، يشير العارض
التكويمي إلى أن النظام قد قرر
استيعاب أكبر للذاكرة في التطبيق
عن طريق تخصيص مزيد من الذاكرة.
زيادة الذاكرة التكويمية إلى
حجم 32 ميجا بايت،
وهو ما يصل من 20 ميغابايت في
جمع البيانات عديمة النفع الأول.
في هذا الوقت لدينا 12.9 ميجابايت
فارغة في الذاكرة التكويمية لدينا
عند هذه النقطة، فإن هذا النظام
يستوعب ديناميكياً
أكبر قدر من الذاكرة
في هذا التطبيق.
إذا تكرر التوسع، قد يؤدي إلى توقف
التطبيق إذا كان النظام لا يمكنه
تخصيص المزيد من الذاكرة للتطبيق.
لذلك تذكر، يعتبر تسرب الذاكرة
بطيء بشكل خبيث ويستغرق وقتا
وبيئة الاختبار المناسبة
للتأكيد على ذلك.
أيضا، ضع في الاعتبار أن
أحيانا نمطا من هذا القبيل
قد يمثل
الاستخدام المسموح به للذاكرة.
على سبيل المثال،
تخيل التطبيق المصمم لمعالجة
. الرسومات الكبيرة أو الصور
الاستبعاد هنا يكون عند رصد
التسرب البطيء للذاكرة، ولكن
دائما تأمل البيانات التي تجمعها،
في مقابل نتائج وآثار الذاكرة
على الوظائف الأساسية لتطبيقك.
في هذه المرحلة، ينبغي أن تفهم
كيف تتسرب الذاكرة بوضوح في SD.
عند هذه النقطة، يجب أن تفهم كيف
تتسرب الذاكرة بوضوح في SDK في
الأدوات المقدمة مثل مراقب
الذاكرة وعارض الذاكرة التكويمية.
لكنك قد لا تعرف
من أين بدأت.
فيما يلي بعض أفضل الممارسات
التي يمكنك اتخاذها لتجنب التسرب.
تتبع حياة أشيائك
أثناء كتابة الكود
مع تنظيف المراجع عندما
لم تعد في حاجة إليها.
حسنا، في الشريحة التالية،
سوف نحدد ما الذي يمكن
ان يكون السبب في هذا التسرب.
Utilizando Heap Viewer, vemos que tras el
primer CG, sólo quedan 1,39 megas libres.
Esto puede indicar que el recolector
de basura no recuperó
mucha memoria, debido a una fuga.
Tras el segundo evento GC, Heap Viewer
indica que el sistema decidió
alojar un mayor uso de memoria
para ésta app, asignando más memoria.
Aumentando el tamaño de la pila
hasta 32 megabytes,
que son más de los 20 megabytes
en el primer GC.
Ésta vez, tenemos 12,9 megabytes libres
en nuestra pila
Aquí, el sistema se está adaptando
dinámicamente
al mayor consumo de memoria de ésta app.
Si la expansión se repite, pudiera
hacer fallar la app, si el sistema ya no
pudiera asignar más memoria para la app.
Recuerda, las fugas de memoria son lentas
e insidiosas, y requieren tiempo
y el ambiente de prueba adecuado
para ser confirmadas.
También ten en cuenta que, a veces,
un patrón como éste
puede representar una utilización
legítima de memoria.
Por ejemplo,
Imagina una aplicación diseñada
para manipular imágenes grandes o fotos.
La moraleja aquí es estar atento a
fugas lentas de memoria, pero
siempre ponderar los datos reunidos
contra las implicaciones de memoria en la
funcionalidad principal de tu app.
Ahora ya deberías entender cómo se
manifiestan las fugas de memoria en la SD.
Ahora ya entenderás como se manifiestan
las fugas de memoria en SDK
usando herramientas como Memory Monitor
y Heap Viewer.
Pero tal vez no sepas
dónde se originan.
Aquí verás algunas mejores prácticas
que adoptar para evitar fugas.
Rastrea la vida de tus objetos
a través de tu código
y limpia las referencias cuando ya
no las necesites.
En la próxima diapositiva,
identificaremos qué pudiera estar
causando ésta fuga.
Avec Heap Viewer, nous voyons qu'après
le1er GC, seulement 1,39 Mo est libéré.
Cela peut indiquer que le garbage
collector ne pouvait en récupérer plus
à cause de la fuite.
Après un 2è événement GC, Heap Viewer
indique que le système a décidé de
d'avoir plus d'empreinte mémoire pour
cette app en allouant plus de mémoire.
Augmentant la taille du tas
de 32 mégaoctets,
une hausse de 20 mégaoctets
par rapport au 1er GC.
Cette fois, nous avons
12,9 mégaoctets de libre dans notre tas.
A ce point, le système s'adapte
dynamiquement à la grande
mémoire d'empreinte de cette application.
Si l'expansion se répète, on peut avoir
un plantage de l'app si le système ne peut
plus allouer plus de mémoire pour l'app.
Alors rappelez-vous, les fuites de mémoire
sont lentes et insidieuses et exigent
du temps et le bon
environnement de test pour confirmer.
Aussi, retenez que
parfois un modèle comme ça
pourrait représenter
une utilisation légitime de la mémoire.
Par exemple,
imaginer une application conçue pour
manipuler de grands graphiques ou photos.
Le truc ici est d'être à l'affût
d'une fuite lente de mémoire, mais
toujours évaluer les données
que vous collectez,
par rapport à la mémoire pour
la fonctionnalité de base de votre app.
Maintenant, vous devez comprendre comment
les fuites de mémoire apparaissent dans SD.
Aussi, vous devez comprendre comment
elles se manifestent dans les outils SDK
comme Memory Monitor et Heap Viewer
Mais vous ne sauriez peut-être pas
d'où elles viennent
Voici quelques pratiques
à faire pour éviter une fuite.
Suivre la vie de vos objets
à travers votre code et
nettoyer les références lorsque
vous en avez plus besoin.
Bien, alors dans la prochaine vidéo,
nous allons identifier ce qui pourrait
être à l'origine de cette fuite.
Menggunakan Heap Viewer,
kita dapat melihat setelah GC pertama
hanya 1,39 megabit yang bebas.
Ini mungkin menunjukkan kolektor sampah
tidak mampu merebut banyak
memori karena kebocoran.
Setelah GC kedua, Heap Viewer
menunjukkan bahwa sistem memutuskan untuk
menampung jejak memori
yang lebih besar untuk aplikasi ini
dengan alokasikan lebih banyak memori.
Meningkatkan ukuran
tumpukan ke 32 megabit,
Yang naik dari 20 megabit di GC pertama.
Kali ini, kita memiliki 12,9 megabit
bebas dalam tumpukan kami.
Pada titik ini, sistem secara dinamis
mengakomodatif untuk
jejak memori yang lebih besar
dari aplikasi ini.
Jika ekspansi terulang,
ini dapat mengakibatkan aplikasi Crash
dan sistem tak lagi bisa mengalokasikan
lebih banyak memori untuk aplikasi.
Jadi ingat, kebocoran memori itu
lambat dan mereka berbahaya
dan membutuhkan waktu dan lingkungan
pengujian yang tepat untuk konfirmasi.
Perlu diingat bahwa
terkadang pola seperti ini
mungkin mewakili penggunaan
yang sah dari memori.
Misalnya,
bayangkan sebuah aplikasi yang dirancang
untuk memanipulasi grafis besar atau foto.
Yang menarik di sini adalah
waspadalah untuk memori bocor yang lambat,
tapi selalu menimbang
data yang Anda kumpulkan,
terhadap implikasi memori
dari fungsi inti aplikasi Anda.
Sekarang Anda seharusnya sudah paham
bagaimana kebocoran memori terjadi di SD.
Pada titik ini, Anda seharusnya paham
bagaimana kebocoran terjadi
dan SDK menyediakan alat
seperti Memory Monitor dan Heap Viewer.
Tapi Anda mungkin tak tahu
dari mana mereka berasal.
Berikut ini beberapa praktik terbaik
untuk menghindari kebocoran.
Melacak kehidupan seluruh kode objek Anda
dan membersihkan referensi saat
Anda tidak lagi membutuhkannya.
Oke, di tampilan berikutnya,
kita akan mengidentifikasi
sebab kebocoran ini.
ヒープビュアを利用すると初GC後に
1.39MBを無料で確認できます
ここでGCはきちんと
調整を行えないかもしれません
メモリリークがあるからです
2番目のGCイベントはヒープビュアが
システムを決定したことを意味します
より大きなメモリのレコードを見たアプリに
より多くのメモリを割当しようとします
ヒープのサイズは32MBに増加して
初GCを行った20MBから
引き上げたのです
今は12.9MBがヒープ内で
フリーな状態です
この時点でシステムは
積極的に受け入れています
アプリのより大きい
メモリレコードのためです
拡張が繰り返される場合
アプリは衝突を起こすでしょう
システムはアプリのための割当を
それ以上行いません
そのため メモリリークが密かに
ゆっくり進んむと時間とmfが必要です
適切なテスト環境を確認しましょう
このようなパターンを見たら
覚えておいてください
メモリを正常的に使用していることを
表示する場合もあります
例えば
アプリの画像はサイズの大きいグラフィック
または写真としてデザインされる時があります
ゆっくりとリークするメモリへの
表面上の対策は
アプリの重要機能は
常に
あなたが集めたデータの大きさで
メモリの影響に対応します
この時点でSD上のメモリが
どういうふうにリークしているかを
提供されたSDKを見て
理解してください
メモリモニターやヒープビュアのような
ツールを使ってです
ですが あなたはそれがどこから
来ているか分からないかもしれません
メモリリークを避ける
最善の方法を紹介します
コードからオブジェクトの寿命を
追跡して
もういらないと判断した時に
参照を片付けます
はい
次のスライドは
リークが行われる時
何が問題か識別しましょう
Heap Viewer로 보면 첫 GC는 1.39MB밖에 확보하지 못했습니다
이건 메모리 누수 때문에
GC가 많은 메모리를 반납하지 못한 가능성을 암시하는데요
두 번째 GC 이벤트 이후 시스템이 애플리케이션에게
추가적으로 메모리를 할당한 게 Heap Viewer를 통해 보입니다
힙 크기가 32MB로 늘었습니다
첫 GC 당시의 20MB 보다 커졌어요
이제 저희 힙에 가용 메모리가 12.9MB만큼 있어요
시스템은 애플리케이션의 메모리 사용량에 반응해
동적으로 메모리 할당량을 늘린 거예요
이 패턴이 반복되어 시스템이 더 이상 애플리케이션에게
메모리를 할당해주지 못하면 애플리케이션은 크래시 됩니다
그러니 기억하세요, 메모리 누수는 서서히 일어나기 때문에
발견하기 위해선 충분한 시간과 적절한 시험 환경이 필요해요
그리고 메모리 할당을 올바르게 해도
이런 패턴이 발생할 수 있다는 점도 잊지 마세요
예를 들어
큰 용량의 삽화나 사진을 조작하는 애플리케이션을 상상해보세요
여기서 교훈은 서서히 누수되는 메모리를 경계하되
수집한 자료와 애플리케이션 핵심 기능의 메모리 사용 방법을 비교해
메모리 누수 여부를 판단하셔야 한다는 겁니다
이제 여러분은 Memory Monitor와 Heap Viewer 같은
SDK에서 제공하는 툴을 사용해
메모리 누수를 찾는 방법을 이해하셨을 거예요
하지만 메모리 누수가 어디서 시작되었는지 모를 수도 있겠네요
그러니 메모리 누수를 방지하는 요령을 알려드릴게요
코드에서 생성하는 객체의 수명을 파악해
더 이상 참조할 필요가 없으면 제거해주세요
좋아요, 그럼 다음 슬라이드에선
이 메모리 누수의 원인을 파헤쳐 볼게요
Usando o visualizador de heap, vemos que
depois do GC, só há 1,30 mega livre.
Isso pode indicar que o Coletor de lixo
não conseguiu recuperar
muita memória devido a um buraco.
Depois do segundo GC, visualizador de heap
indicou que o sistema decidiu
armazenar uma memória maior para esse
aplicativo atribuindo mais memória.
Aumentando o tamanho do heap para 32 megas,
que era 20 megas no primeiro GC.
Agora, temos 12.9 megas livres no heap.
Agora, o sistema está
acomodando dinamicamente
para um espaço de memória maior
desse aplicativo.
Se a expansão se repetir,
pode travar o aplicativo se o sistema
não disponibilizar mais memória
para o aplicativo.
Lembre-se, as perdas de memória
são lentas e traiçoeiras
e requerem teste apropriado
do ambiente para confirmação.
Tenha em mente que algumas vezes
um padrão como esse
pode representar
um uso legítimo da memória.
Por exemplo,
imagine um aplicativo feito para
manipular muitos gráficos ou fotos.
A chave aqui é analisar
a memória de vazamento lento
sempre medir sua coleta de dados,
diante dos resultados de memória
da funcionalidade do aplicativo.
Agora, você já deve entender como
o vazamento da memória se dá no SD.
Já deve entender como
o vazamento da memória se manifesta nas
ferramentas SDK como o Monitor de Memória
e o Visualizador de Heap.
Mas você talvez não saiba
da onde eles vem.
Essas são algumas das práticas que você
pode adotar para evitar o vazamento.
Procure a existência dos objetos
por todo o código e
apague as referências
que você não precisa mais.
Certo, então no próximo slide,
vamos identificar o que
pode causar esse vazamento.
Heap Viewer показывает, что после первого
СМ было освобождено только 1,39 МБ памяти.
Это может служить индикатором того,
что сборщик мусора не смог вернуть
достаточно памяти из-за утечки.
После второго события СМ, Heap Viewer
показывает, что система приняла решение
выделить больше памяти этому приложению,
тем самым повышая доступный объём
динамической памяти до 32 мегабайт,
что выше тех 20 мегабайт, которые имелись
в момент первого запуска СМ.
Теперь у нас имеется 12,9 мегабайт
свободной памяти.
В данный момент система
динамически распределяет
более высокий объём памяти для приложения.
Если рост повторяется, это может привести
к падению приложения, если система
больше не сможет выделять память.
Итак, запомните, утечки памяти могут быть
медленными и хитрыми и требовать времени и
правильной среды для их нахождения.
Также помните,
что иногда подобное поведение
может означать, что память используется
нормальным образом.
Например,
представим приложение, которое служит для
обработки больших схем или фотографий.
Здесь важно следить
за медленно утекающей памятью,
однако всегда оценивайте собранные данные
с точки зрения задействования памяти
в основной работе вашего приложения.
Сейчас вы должны понимать,
как утечки памяти проявляются в SDK.
Сейчас вы должны понимать,
как утечки памяти проявляются в SDK
при помощи таких инструментов,
как Memory Monitor и Heap Viewer.
Однако, вы можете не знать,
откуда они появились.
Вот несколько советов,
как избежать утечек.
Следите за жизненным циклом объектов
по всей программе,
и удаляйте ссылки,
когда они больше не используются.
А на следующем слайде
мы определим,
что могло вызвать утечку.
Yığın izleyici kullanarak, ilk GC'den sonra
yalnızca 1.39 milyonun boş olduğunu
görüyoruz. Bu, çöp toplayıcısının
sızıntıdan dolayı çok fazla
hafızayı iyileştirediğini gösterebilir.
İkinci bir GC olayından sonra,
yığın izleyici sistemin, bu uygulama
için daha fazla hafızayı bölerek
daha geniş bellek parmak izi düzenlemesine
karar verdiğini göstermektedir.
Yığın boyutunu 32
megabyte'a çıkartarak, ki
20 megabyte'dan ilk GV'de daha yukarıdadır.
Bu sefer yığınımızda
12.9 megabyte'ımız var.
Bu noktada, sistem dramatik
olarak bu uygulamanın
daha geniş kapladığı alan
için bunu denkleştirir.
Genişleme tekrar ederse, bu uygulama
kazasına neden olabilir, eğer sistem
artık daha fazla uygulama
için hafıza dağıtamazsa.
O zaman unutmayın, hafıza sızıntısı
yavaş olur ve bunlar sinsidir ve
onaylamak için düzgün test
ortamı gerektirir ve bu zaman alır.
Aynı zamanda, bunun gibi bir modelin
hafızanın meşru kullanımını
temsil edebileceğini unutmayın.
Örneğin, geniş grafikler veya
fotoğrafları çalıştırmak
için dizayn edilmiş bir
uygulamanın olduğunu farzedin.
Paketleme servisi burada yavaş hafıza
sızıntısı için tetikte beklemektedir ancak
daima uygulamanızın çekirdek
işlevliğinin hafıza
sonuçlarına karşı topladığınız
verileri tartmaktadır.
Bu noktada, SD'de hafızanın manifestoya
nasıl sızdığını anlayabilirsiniz.
Bu noktada, Hafıza Monitörü ve
Yığın İzleyicisi gibi sağlanmış
olan araçların hafızanın SDK manifestosuna
nasıl sızdığını anlamanız gerekir.
Ancak nereden kaynaklandığını
bilemeyebilirsiniz.
Sızıntıdan kaçınmak için işte size
bazı iyi çalışma yöntemleri.
Kodunuz boyunca objelerinizin hayatını
takip edin ve ihtiyacınız olmadığında
kaynakları (referansları) temizleyin.
Tamam, bir sonraki slayt
gösteriminde bu sızıntıya
neyin neden olabileceğiniz
tanımlayacağız.
Với heap viewer, chúng ta có thể thấy sau
GC đầu tiên, chỉ có 1,39 megs còn trống.
Điều này có thể cho thấy bộ
garbage collector đã không thể dành lại
nhiều bộ nhớ do một lỗ hổng.
Sau sự kiện GC thứ hai, Heap Viewer
chỉ ra rằng hệ thống đã quyết định
cấp lượng bộ nhớ lớn hơn cho ứng dụng này
bằng cách phân bổ thêm bộ nhớ.
Tăng kích thước vùng
lên 32 megabyte,
từ 20 megabyte
trong GC đầu tiên.
Lần này, chúng ta còn
12,9 megabyte trống trong vùng.
Đến lúc này, hệ thống
đã tự động cấp
bộ nhớ lớn hơn cho ứng dụng này.
Nếu việc mở rộng lặp lại, nó có thể khiến
ứng dụng sụp đổ
nếu hệ thống không thể
cấp thêm bộ nhớ cho ứng dụng này nữa.
Vì vậy, hãy nhớ, lỗ hổng bộ nhớ rất chậm
chạp và ngấm ngầm,
nó cần thời gian và điều kiện thử nghiệm
đúng chuẩn mới có thể xác định.
Ngoài ra, hãy nhớ rằng
đôi khi một mô hình như thế này
cũng có thể đại diện cho
việc sử dụng bộ nhớ hợp lệ.
Ví dụ như,
hãy tưởng tượng ứng dụng được thiết kế
để thao tác các đồ họa hoặc hình ảnh lớn.
Việc sử dụng ở đây nhìn trực giác giống
như bộ nhớ đang bị rò rỉ chậm, nhưng hãy
luôn cân nhắc những dữ liệu bạn thu được
với những biểu hiện của bộ nhớ về
chức năng cốt lõi của ứng dụng đó.
Bây giờ tại điểm này, bạn sẽ hiểu được
cách mà lỗ hổng bộ nhớ thể hiển trong SD.
Tại điểm này, bạn sẽ hiểu được cách
lỗ hổng bộ nhớ thể hiện
trong các công cụ SDK như Memory Monitor
hay Heap Viewer.
Nhưng bạn có thể không biết
nguồn gốc của chúng.
Dưới đây là một số việc tốt nhất
bạn có thể làm để tránh lỗ hổng.
Theo dõi sự tồn tại của các đối tượng
thông qua mã của bạn
dọn dẹp các tham chiếu khi
bạn không cần đến chúng nữa.
Ok, và trong slide tiếp theo,
ta sẽ xác định điều gì có thể
tạo những lỗ hổng này.
通过heap viewer,可知第一次GC仅释放了1.39兆内存。
这种结果显示,因为漏洞的存在,
垃圾清理无法回收全剖垃圾。
Heap viewer显示第二次GC后,
系统必须经由配置更多的内存,来调整内存量。
堆从第一次GC的20兆,
增加到32兆。
此次Java堆释放了12.9兆。
这时,
系统不断地为程序配置更多的内存。
以上动作如果一再重复,系统终会无法配置内存。
程序也就挂了。
切记,内存漏洞非常缓慢又不易被发现,
需要时间,跟适当的环境来确认,
有时,这样的数据,
也表示内存的正当存取。
比如
处理图片跟照片的程序,
表面看似内存在泄漏,
实际上它针对核心功能的存储器,
不停地进行数据评估。
因此,要明白内存漏洞如何显示在SD上。
也要清楚,内存漏洞如何显示在拥有SDK的工具上。
如Memory Monitor和Heap Viewer。
但是,各位可能不知道他们源于何地,
以下这些方法,可以防止漏洞的出现。
利用编码查看程序的寿命,
清理不用的文件。
接下来,
辨别漏洞产生的原因。
透過heap viewer可知第一次GC僅釋放1.39兆內存
這種結果顯示因為漏洞的存在
碎片帳集無法回收全部的垃圾
Heap Viewer顯示第二次GC後
系統必須經由配置更多的內存來調整內存量
堆從第一次GC的20兆
增加到32兆
此次Java堆釋放 了12.9兆
此時
系統不斷地為程式配置更多的內存
此動作如果一再地重復 系統最終無法配置內存
程式也就當掉了
切記內存漏洞非常緩慢且不易被查覺
需要時間跟適當的環境來確定
有時這樣的數據
也表示內存的正當存取
如
處理圖像跟照片的程式
表面看似內存在泄漏
實質上牠針對核心功能的存儲器
不時地進行數據評估
因此要明白內存漏洞如何呈現在SD上
也要明白內存漏洞如何呈現在擁有SDK的工具上
如Memory Monitor和
Heap Viewer
但大家可能不知道他們源於何處
以下這些方式可以防止漏洞的出現
利用編碼查看程式的壽命
清理無用的資料
接下來
辨識漏洞產生的原因